Notifications

SiteQwality’s notifications system has four objects and they often get confused. This page is the map.

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, call at 5min”

The first two are account-wide; the last two are personal, and every team member configures their own. The two layers are decoupled on purpose: the team picks “where this monitor’s alerts go” once; each engineer picks “how I personally want to be paged.”

Channels (notifications)

A channel is a single delivery destination. Each channel has a type and details specific to that type:

Type	Required details
email	email_address
sms	country_code (int), phone_number
slack	integration_id (a Slack integration UUID), channel (#ops)
webhook	integration_id (a webhook integration UUID, with the URL held on the integration)
telegram	telegram_integration_id
discord	discord_integration_id
microsoft_teams	teams_integration_id
pagerduty	pagerduty_integration_id, optional pagerduty_severity
opsgenie	opsgenie_integration_id
google_chat	google_chat_integration_id
mattermost	mattermost_integration_id
pushover	pushover_integration_id
pushbullet	pushbullet_integration_id

Every type except email and sms references an integration; set those up first under Integrations.

See the channels reference for the per-type details shape, the delivery guarantees table, and which monitor types each channel supports.

Channels live inside a notification group; you don’t attach raw channels to monitors.

Notification groups

A notification group is the bag of channels you attach to a monitor. Two extra knobs let you control timing:

Field	Purpose
delay_send_after_minutes	Wait this long before sending the first alert. Suppresses brief flapping. Clamped 0–60.
resend_every_minutes	If the incident is still active and unacknowledged, re-send every N minutes. Clamped 0–60.

The delay is the cleanest way to suppress noise: if a check fails for one tick and recovers, no notification fires.

A monitor can attach to multiple groups (cap of 10 per monitor), which is useful when you want a single check to alert both an internal team and a customer-facing channel.

Contact methods (per user)

Each user defines how they personally can be reached, under Settings → My profile → Contact methods:

Type	Detail
email	An email address (auto-populated with sign-up address).
sms	A phone number.
phone_call	Same number. Not delivered today, see below.
slack_dm	DM via the Slack integration.

Contact methods are not attached to monitors. They power escalation paging: when an escalation level targets target_user_ids, that user’s notification rules determine which contact methods fire.

Two honest limits on contact methods

phone_call does not deliver. The type exists and you can create rules against it, but the escalation engine has no phone-call transport, so a rule pointing at a phone_call contact method is skipped at send time. Do not rely on it as your last-resort escalation step; use SMS or a push channel instead.

verified is not enforced at paging time. The flag records whether the user confirmed the destination, but escalation paging does not check it before sending. An unverified SMS number will be attempted.

Notification rules (per user)

Personal preferences for “if I’m being paged at urgency X, fire this contact method after this many minutes.” Stack multiple 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 is high or low, and it is derived from the incident’s severity rather than chosen: critical and major page at high urgency, minor pages at low. A user with no rule matching the incident’s urgency is simply not paged.

delay_minutes defaults to 0 and is not range-validated. A rule with a delay becomes a scheduled one-shot, and when it fires the system re-checks that the incident is still triggered, the escalation has not been acknowledged, and the rule still exists. Anything that changed in the meantime cancels the send, so a delayed rule cannot page you about an incident you already acked.

position orders the rules in the list; it does not stagger them. Every matching rule fires in the same pass, each waiting only its own delay_minutes.

How a page actually fires

1. Monitor flips, opens an incident.
2. Incident attaches to the monitor’s group_notification_ids.
3. For each notification group:
   • Wait delay_send_after_minutes (if any).
   • Fan out to every channel in the group.
4. If an escalation policy is wired in via the routing path, page targeted users:
   • For each user, walk their notification rules for the incident’s urgency.
   • Each rule waits its delay_minutes, then fires its contact method.
5. If no ack within the level’s timeout_minutes, advance to the next escalation level.
6. Optional resend_every_minutes re-fires the channel fanout in step 3.

Pricing

Email, Slack, webhook, Discord, Teams, Telegram, PagerDuty, OpsGenie, Google Chat, Mattermost, Pushover, and Pushbullet are included on every plan. SMS delivery costs real money (Twilio pass-through) and is billed per page on paid plans.

See also

Channels reference Every channel type with required fields.

Set up notification rules Personal delivery preferences for high vs low urgency.

Integrations Connect Slack, Teams, Discord, Telegram, webhooks.