Notifications
Notifications are built from four objects: two shared by the account, two personal to each user.
| Object | Owner | Purpose | Example |
|---|---|---|---|
| Channel (a.k.a. notification) | account | One delivery destination | ”Send to #ops in our Slack” |
| Notification group | account | Bundle of channels attached to a monitor | ”Default alerts” → email + Slack + webhook |
| Contact method | user (personal) | One way to reach me | ”My phone for SMS” |
| Notification rule | user (personal) | Per-urgency delivery preferences for me | ”High urgency? SMS at 0min, email at 5min” |
The team picks where a monitor’s alerts go once; each engineer picks how they personally want to be paged.
Channels (notifications)
Section titled “Channels (notifications)”A channel is a single delivery destination: email, SMS, Slack, webhook, Telegram, Discord, Microsoft Teams, PagerDuty, Jira Service Management (Opsgenie), Google Chat, Mattermost, Pushover or Pushbullet. Every type except email and SMS references an integration; set those up first under Manage → Integrations.
Channels live inside a notification group; you don’t attach raw channels to monitors. See the channels reference for each type’s details and which alerts reach which channels.
Notification groups
Section titled “Notification groups”A notification group is the bag of channels you attach to a monitor. In the dashboard, groups live under Respond → Notifications, and Add notification method adds a channel to a group.
Two extra knobs, under Advanced settings in the group, control timing:
| Dashboard field | API field | Purpose |
|---|---|---|
| Delay after (minutes) | delay_send_after_minutes | Wait this long before sending the first down alert. Clamped 0–60. |
| Resend every (minutes) | resend_every_minutes | While the monitor is still down, re-send the down alert every N minutes, at most 10 times. 0 turns repeats off; other values are clamped to 5–60. |
Both apply to down alerts from HTTP monitors, heartbeats and browser checks only; every other alert, and every recovery, sends at once (see the group delay).
A repeat stops when the monitor recovers, or earlier when someone acknowledges the outage and the account’s outage_ack_stops_repeats notification setting is on (the default). The recovery alert is still sent. When a repeat is set, the first down alert also waits for the first scheduled send. The same settings page decides whether monitors hold alerts while they flap.
New monitors created without groups get the account’s default group, which at signup is Default: one email channel to the address you signed up with. See the default notification group.
A monitor can attach to up to 10 groups, for example to alert both an internal team and a customer-facing channel.
Contact methods (per user)
Section titled “Contact methods (per user)”Each user sets how they personally can be reached, in their personal settings under Notifications → Contact methods (open the menu under your name, bottom left):
| Type | Detail |
|---|---|
email | An email address. New users get their sign-in email added for them, already verified. |
sms | A phone number in any country. It must be verified with a 6-digit code before a rule can use it. |
slack_dm | Linked from Slack: run /oncall in a workspace your account has connected and open the link, and it sends through that Slack integration. Or a Slack bot token you paste in, with the channel or user ID to message, which does not use the Slack integration. |
There are no phone calls. Each user can have up to 20 contact methods. See add and verify contact methods.
Contact methods are not attached to monitors. They are used for incident pages: when an escalation level pages a user, that user’s notification rules decide which contact methods fire.
Notification rules (per user)
Section titled “Notification rules (per user)”Personal preferences for “if I’m being paged at urgency X, fire this contact method after this many minutes.” A new user starts with two rules on their sign-in email, one high and one low, both at 0 minutes. Stack rules at increasing delays for personal escalation:
[ { "urgency": "high", "contact_method_id": "<sms-id>", "delay_minutes": 0, "position": 0 }, { "urgency": "high", "contact_method_id": "<slack-dm-id>","delay_minutes": 5, "position": 1 }, { "urgency": "high", "contact_method_id": "<email-id>", "delay_minutes": 15, "position": 2 }]That’s: SMS me immediately, Slack DM me if I haven’t acked in 5 minutes, email me if I haven’t acked in 15.
Urgency comes from the incident’s severity: critical and major page at high urgency, minor at low. A user no rule can reach is paged at their sign-in email instead (see the fallback). Set up notification rules covers delays and ordering.
How a page fires
Section titled “How a page fires”Monitor alerts and incident pages take separate paths:
- Monitor alerts go straight to the monitor’s notification groups, with no incident involved.
- Incidents page people through the escalation policy of the incident’s service. Each level pages its users through their notification rules, and if no one acknowledges within the level’s
timeout_minutes, the next level is paged.
Who gets notified covers both, plus the default group and monitors that notify no one.
Pricing
Section titled “Pricing”SMS uses SMS credits, sold in packs. See pricing.