PB PulseBeacon Docs
Home / Docs / Notification Rules

Alerting

Notification Rules

Control which events should alert and where alerts should be delivered.

Notification rules decide which events should alert and which integrations should receive them. Rules are user-scoped and can target all resources or a specific check/server.

How a Rule Works

  • Name: label for your team
  • Scope: all resources, one check, or one server
  • Events: choose what should trigger alerts
  • Integrations: one or more active channels

Scope Filtering

PulseBeacon shows and applies only event types relevant to the scope you selected.

Available Events

check_down
Check DOWN
check_up
Check back UP
check_late
Check LATE (missed schedule)
check_slow
Check slow / high latency
check_paused
Check paused
check_resumed
Check resumed
keyword_missing
Keyword missing / mismatch
keyword_restored
Keyword restored
ssl_expiring
SSL expiring soon
ssl_expired
SSL expired / invalid
ssl_ok
SSL healthy again
port_closed
Port closed / unreachable
port_open
Port open again
server_offline
Server OFFLINE
server_online
Server back ONLINE
server_high_cpu
High CPU usage
server_high_mem
High memory usage
server_high_disk
High disk usage

Practical Rule Patterns

Production critical checks 
Scope: check
Selected check: API - Production
Events: check_down, check_late, check_up
Integrations: Slack (Ops), Telegram (On-call)
Server resource alerts 
Scope: server
Selected server: app-eu-1
Events: server_offline, server_high_cpu, server_high_mem, server_high_disk
Integrations: Slack (Infra), Email (NOC)
SSL focused alerts 
Scope: any
Events: ssl_expiring, ssl_expired, ssl_ok
Integrations: Email (Security), Discord (Ops)

When Alerts Actually Fire

  • Alerts fire on confirmed state transitions only — never on every failed probe. A transient blip that recovers during confirmation sends nothing.
  • check_down is sent once when an outage is confirmed; check_up once when recovery is confirmed.
  • See Reliability & Alerting for the confirmation model.

Deduplication & Safeguards

  • Identical repeated transitions are deduplicated with a cooldown window on every channel — email, webhook, Slack, Telegram, and Discord.
  • The email channel additionally has hourly/daily volume safeguards to suppress alert storms.
  • Suppressed events are recorded as skipped notification events with reason text, so you can always see why something was not sent.
  • Sensitive values (authorization headers, tokens, URL credentials) are redacted from alert payloads.
  • Always keep at least one broad fallback rule so critical events never route to zero channels.