Skip to content

Notification Behavior

The exact specification of when, where, and how many times notifications are sent. For per-channel setup, see the notification guides.

EventTimingSeverity
Incident createdWhen an incident is confirmed after 5 consecutive down checkscritical
Warning incident createdWhen a monitor becomes degradedwarning
Incident resolvedOn automatic resolution after recovery
Web change detectedWhen a Web Change monitor detects a difference
Maintenance started / endedAt the start and end of a maintenance window
  1. If a monitor has at least one channel attached directly, notifications go only to the active, verified channels among them (team-wide channels are not used)
  2. If the monitor has no direct channels, notifications go to the team-wide active, verified channels
  3. If no eligible channel exists, nothing is sent

When a monitor rapidly alternates between down and up (flapping), suppression prevents a notification flood.

  • If a monitor generates more than 3 notification events within the last 10 minutes, subsequent notifications are suppressed
  • The counter automatically expires after 10 minutes
  • Incidents are still recorded while suppressed (visible in the dashboard)
  • Maintenance start/end notifications are exempt from flap suppression

The same combination of incident, channel, and event type is sent at most once. Even if the delivery infrastructure retries, you will not receive the same notification twice.

If some channels fail while sending to multiple channels, the remaining channels are still attempted. Delivery counts as complete if at least one channel succeeds; it is retried only when every channel fails.

Separate from notification channels, webhook subscriptions deliver events over HTTP.

  • Events: incident.created / incident.resolved / webchange.detected (only subscribed events are delivered)
  • Delivery is attempted up to 3 times — the initial send plus up to 2 retries (best-effort delivery)