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
}

Which alerts reach which channels

Not every alert source reaches every channel type. A channel of a type the source does not support is skipped: no alert arrives on it, and a skipped receipt records why. Saving the monitor still succeeds, with a warning. Alert coverage lists which monitor and rule alerts reach each channel type, how incidents, escalations and status pages reach people, and what each skip reason means. Keep an email or SMS channel in every group that has to page someone.

Skipped deliveries

When Site Qwality skips a channel, it records a receipt with the status skipped and a reason code. Alert coverage lists every reason code, what it means and whether it marks the channel degraded.

Skipped receipts appear in a channel’s recent deliveries (health.recent on GET /notification/{id} and on each channel in GET /notification_group) and in a monitor’s alert history (GET /monitors/{id}/alert_history, with the slug in detail). Some skips, such as recipient_suppressed, also set the channel’s health.state to degraded; a skip by design, such as heartbeat_channel_unsupported, does not.

An email channel whose address hard-bounced or complained after its last delivered alert is degraded too, with health.bouncing naming when (since), the event_type (bounce or complaint) and the sub_type. It recovers when a later alert to the channel is delivered. Every channel’s alerts are listed in the delivery history.

Warnings when you save a monitor

Creating or updating an HTTP, heartbeat or DNS record monitor still succeeds when one of its notification groups holds a channel its alerts cannot reach. The response carries a warnings array beside data, one entry per channel and alert source:

"warnings": [
  {
    "code": "channel_not_supported_for_source",
    "message": "Heartbeat alerts cannot be sent to Discord yet, so \"On-call\" will skip that channel for them.",
    "notification_group_id": "<group-uuid>",
    "notification_id": "<channel-uuid>",
    "channel": "discord",
    "source": "heartbeat",
    "reason": "heartbeat_channel_unsupported"
  }
]

source is heartbeat, tls_expiry, page_speed or dns_record, and reason is the slug the skipped receipts will carry. An HTTP monitor is also checked for the alerts of its paired TLS and page speed checks. The field is left out when there is nothing to warn about.

Email

{
  "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 Site Qwality <no-reply@notifications.siteqwality.com>. Allow it to avoid spam folders.
The subject names the monitor type, the state and the monitor (for example [HTTP down] prod-api); the body links to the monitor in the dashboard. Down alerts for HTTP monitors, heartbeat (cron) monitors and browser checks also carry a single-use acknowledge link.

SMS

{
  "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.
Delivery is best-effort. For critical pages, pair SMS with a second channel such as email or a push app.

Slack

{
  "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. The app must be added to private channels.
Monitor alerts render as a message attachment with a status color, the monitor name and URL, with no buttons.
Incident messages link to the incident in Site Qwality and have no buttons. Acknowledge and resolve from the incident page.

Webhook

{
  "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 signed JSON POST with an event envelope. See Integrations → Webhooks for events, headers and signature checks.

Sample webhook body (data truncated):

{
  "id": "<delivery-uuid>",
  "event": "monitor.down",
  "severity": "critical",
  "created_at": "2026-03-14T09:26:53Z",
  "account_id": "<account-uuid>",
  "data": {
    "http_job_id": "<monitor-uuid>",
    "request_uri": "https://api.example.com",
    "response_http_code": 503,
    "status": "failed"
  }
}

{
  "type": "telegram",
  "details": { "telegram_integration_id": "<telegram-integration-uuid>" }
}

Setup is two-step: start a setup code, send it to the bot, then finalize. See Integrations → Telegram.
Messages render as HTML-formatted text with the monitor name, URL and state. They have no link back to Site Qwality.

Discord

{
  "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 a status color and the monitor details. They have no link back to Site Qwality.

Microsoft Teams

{
  "type": "microsoft_teams",
  "details": { "teams_integration_id": "<teams-integration-uuid>" }
}

Teams integration uses a Workflows webhook URL for a Teams channel. Office 365 connector URLs do not work. See Integrations → Microsoft Teams.
Messages render as Adaptive Cards with a status color.

PagerDuty

{
  "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.

Jira Service Management (Opsgenie)

{
  "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.
The channel type is opsgenie. See Integrations → Jira Service Management (Opsgenie).

Google Chat

{
  "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.
See Integrations → Google Chat.

Mattermost

{
  "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.
See Integrations → Mattermost.

Pushover

{
  "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.

Pushbullet

{
  "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.

Delivery guarantees by channel

What each channel does when a send fails:

Channels	On failure
Webhooks	Up to 8 attempts over about 27.6 hours. Every attempt is in the endpoint’s delivery log. While retries are pending the alert’s receipt reads `delayed`; when they end it becomes `delivered`, `failed` or `rejected`.
PagerDuty, Jira Service Management (Opsgenie)	3 attempts. A `4xx` other than `408` or `429` is recorded as rejected. Other failures run the send again up to twice; after that the alert is dropped with no record.
Pushover, Pushbullet	1 attempt. A `4xx` is recorded as rejected. A Pushover `429` means the Pushover account used its monthly message limit, and is recorded as rejected too. Other failures run the send again up to twice; after that the alert is dropped with no record.
Email, SMS, Slack, Telegram	1 attempt. A refusal is recorded as rejected, and an SMS to a number that opted out is skipped (`recipient_suppressed`). Other failures run the send again up to twice; after that the alert is dropped with no record.
Discord, Microsoft Teams, Google Chat, Mattermost	Up to 3 attempts in quick succession, with no redirect followed. A `400`, `401`, `403`, `404`, `410` or redirect is recorded once as rejected. A timeout after the request went out is not sent again, since it may have arrived. The failure is always recorded.

For a page that must arrive, use more than one channel type.

Common pitfalls

Channel created but no notifications arrive. Check that the channel is in a group and the group is attached to the monitor.
Channel save refused. A channel must name an integration of its own type in your account, so a mistyped ID or an ID of another integration type is refused. Copy the ID from GET /integration.
Alerts show as skipped. See Skipped deliveries for the reason codes.
SMS not arriving. Verify the country code is the integer prefix (1, not "+1"); confirm the number is plain digits.