Skip to content

Channels reference

A channel (also called a notification in the API) is a single delivery destination. Channels live inside a notification group, which is what you attach to monitors.

Every channel has:

{
"notification_group_id": "<group-uuid>",
"type": "email|sms|slack|webhook|telegram|discord|microsoft_teams|pagerduty|opsgenie|google_chat|mattermost|pushover|pushbullet",
"details": { ... } // type-specific fields
}

This page documents details for each type.

{
"type": "email",
"details": { "email_address": "alerts@example.com" }
}
  • Validated against a basic email regex.
  • No verification step, so anything that parses as an email is accepted.
  • Sender is alerts@siteqwality.com. Whitelist it to avoid spam folders.
  • Subject line includes monitor name + status; body includes a deep link to the incident.
{
"type": "sms",
"details": {
"country_code": 1,
"phone_number": "5551234567"
}
}
  • country_code is the country dialing prefix as an integer (1 for US, 44 for UK, 49 for DE, etc).
  • phone_number is the local number with no formatting characters.
  • Validation requires a parseable phone number.
  • Costs Twilio pass-through rates; billed per page on paid plans.
{
"type": "slack",
"details": {
"integration_id": "<slack-integration-uuid>",
"channel": "#ops"
}
}
  • Requires a Slack integration first. See Integrations → Slack.
  • channel accepts #name or a Slack channel ID. Bot must be invited to private channels.
  • Messages render as rich blocks with status color, monitor name, recent results, and an “Acknowledge” interactive button.
{
"type": "webhook",
"details": { "integration_id": "<webhook-integration-uuid>" }
}
  • The URL lives on the integration object (/integration/webhook), not the channel, so multiple channels can share one URL with different downstream meaning.
  • Payload is a JSON POST with the incident object + monitor context.

Sample webhook body (truncated):

{
"event": "incident.opened",
"incident": {
"id": "<incident-uuid>",
"title": "HTTP check failure: prod-api",
"severity": "major",
"status": "investigating"
},
"monitor": { "id": "<job-uuid>", "type": "http", "uri": "https://api.example.com" }
}
{
"type": "telegram",
"details": { "telegram_integration_id": "<telegram-integration-uuid>" }
}
  • Setup is two-step: create a setup state, send your bot a code, then finalize. See Integrations → Telegram.
  • Messages render as HTML-formatted text with a deep link to the incident.
{
"type": "discord",
"details": { "discord_integration_id": "<discord-integration-uuid>" }
}
  • Discord integration uses an incoming webhook URL (created in your Discord server settings).
  • Messages render as embeds with status color and incident link.
{
"type": "microsoft_teams",
"details": { "teams_integration_id": "<teams-integration-uuid>" }
}
  • Teams integration uses an incoming webhook URL from a Teams channel connector.
  • Messages render as Adaptive Cards with status color.
{
"type": "pagerduty",
"details": {
"pagerduty_integration_id": "<pagerduty-integration-uuid>",
"pagerduty_severity": "critical"
}
}
  • pagerduty_severity is optional and defaults to critical. Values: critical, error, warning, info.
  • Outages trigger a PagerDuty incident; recoveries resolve the same one via a shared dedup key.
  • Domain expiry warnings always send at warning regardless of this setting, and never auto-resolve.
  • See Integrations → PagerDuty.
{
"type": "opsgenie",
"details": { "opsgenie_integration_id": "<opsgenie-integration-uuid>" }
}
  • No per-channel priority field. Outages are P1, domain expiry warnings are P3.
  • Recoveries close the alert by alias. Domain expiry alerts never close on their own.
  • See Integrations → OpsGenie.
{
"type": "google_chat",
"details": { "google_chat_integration_id": "<google-chat-integration-uuid>" }
}
  • The integration holds a space incoming webhook URL, which is readable back through GET /integration.
  • Messages render as Google Chat cards.
  • Sends that fail 3 times are recorded and dropped rather than retried further. See Integrations → Google Chat.
{
"type": "mattermost",
"details": { "mattermost_integration_id": "<mattermost-integration-uuid>" }
}
  • The integration holds an incoming webhook URL, readable back through GET /integration.
  • Messages render as Slack-style attachments with a status color.
  • Same 3-attempts-then-drop behavior as Google Chat. See Integrations → Mattermost.
{
"type": "pushover",
"details": { "pushover_integration_id": "<pushover-integration-uuid>" }
}
  • The integration holds both a user (or group) key and an application API token.
  • Outages send at priority 1 (bypasses quiet hours); recoveries and expiry warnings at 0.
  • See Integrations → Pushover.
{
"type": "pushbullet",
"details": { "pushbullet_integration_id": "<pushbullet-integration-uuid>" }
}
  • The integration holds an account access token.
  • Messages arrive as note pushes on every signed-in device.
  • See Integrations → Pushbullet.

Not all channels behave the same when a send fails. This matters when you are choosing which channel to trust for a critical page.

ChannelsOn failure
PagerDuty, OpsGenie3 in-process attempts (safe, the calls are idempotent), then the event is failed and retried.
Email, SMS, Slack, Telegram, Pushover, Pushbullet1 attempt, then the event is failed and retried. Duplicates are possible; lost alerts are not silent.
Discord, Microsoft Teams, Google Chat, Mattermost3 attempts, then the failure is recorded and the message is dropped. Nothing retries it.
Customer webhooks3 attempts, then the failure is recorded and dropped.
  • Channel created but no notifications arrive. First check whether the channel is attached to a group and the group is attached to the monitor. Channels alone don’t deliver.
  • Slack/webhook channels saying integration not found. The integration must exist on the same account and be referenced by UUID.
  • SMS not arriving. Verify the country code is the integer prefix (1, not "+1"); confirm the number is plain digits.