Who gets notified

Site Qwality has two separate routing paths. A monitor alert and an incident page never share a route, so set up the one you need.

Two paths

Monitor alerts                          Incident pages

Monitor goes down or recovers           Incident opens on a service
          │                                       │
          ▼                                       ▼
Monitor's notification groups           Service's escalation policy
          │                                       │
          ▼                                       ▼
Every channel in each group             Each targeted user's notification
(email, SMS, Slack, webhook, ...)       rules, then their contact methods

Monitor alerts go to the notification groups attached to the monitor (group_notification_ids). No incident is involved, and nobody acknowledges them.

Incident pages go through the escalation policy of the incident’s service. Each level pages its users, and each user’s notification rules decide which of their contact methods fire. An incident opens automatically only when a monitor is linked to a service whose incident_creation_mode is auto; otherwise you open it by hand.

A monitor linked to such a service uses both paths: its groups send the monitor alert, and the incident pages the on-call.

The default notification group

Signup creates a group named Default. It holds one email channel to the address you signed up with, and waits 3 minutes before sending a down alert.

The Default group is the account’s default notification group: the group new monitors get when you do not choose one. On older accounts, the group named “Default” is the default group, if it still exists.

Dashboard: the create form pre-selects the default group. Clear it, or pick other groups, before you save.
API, MCP, CSV import and Terraform: when a create omits group_notification_ids or sends null, the monitor is attached to the default group. This applies to HTTP monitors, heartbeat (cron) monitors, browser checks and DNS record monitors.

An explicit empty list, "group_notification_ids": [], means “notify nobody”, and the monitor is created without groups.

Change the default group

Any group can be the default. Open Notifications, edit the group, and turn on Use for new monitors. The group that held the flag before loses it. Existing monitors keep the groups they have.

Through the API, set is_default on the group:

curl -X PUT https://api.siteqwality.com/notification_group/$GROUP_ID \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "is_default": true }'

Every group object includes is_default, and at most one group per account has it set to true. POST /notification_group accepts is_default too.

With no default group

If you delete the default group, or set "is_default": false on it, the account has no default. New monitors created without groups then notify no one. The dashboard form starts with no group selected, and API creates that omit group_notification_ids attach nothing.

Monitors that notify no one

A monitor notifies no one when none of its notification groups has a channel, and it is not linked to a service that creates incidents automatically and pages someone (through an escalation policy or the service’s notification targets).

The monitor list shows No one is notified on active monitors in that state.
Once per account, the dashboard shows a banner that lists those monitors so you can attach a group. Dismissing the banner hides it for the whole account, permanently.

Through the API, GET /monitors returns notifies_no_one on each row (it is computed for paused monitors too), and GET /monitors/silent lists the active ones:

{
  "data": {
    "monitors": [
      { "id": "3f2c8a9e-5b1d-4c7a-9e0f-1a2b3c4d5e6f", "monitor_type": "http", "friendly_name": "Checkout API" }
    ],
    "total": 1,
    "banner_dismissed": false,
    "has_default_group": true
  }
}

monitors is sorted by name and holds at most 100 entries; total is the full count. monitor_type is http, cron, browser or dns_record.

The group delay

A group’s delay_send_after_minutes holds back the first down alert. The Default group uses 3 minutes: alerts wait 3 minutes, then send if the monitor is still down. With 0 or no delay, alerts send as soon as a check fails.

The delay applies today to down alerts from HTTP monitors and browser checks only.

Alert	Group delay
HTTP monitor down	Applies
Browser check down	Applies
Heartbeat (cron) down	Sends at once
TLS expiry, domain expiry, DNS record, page speed	Sends at once
Recovery (up) alerts, every type	Sends at once

To stop a single failed check from paging anyone, raise the monitor’s confirmation threshold instead. The delay does not stop an incident from opening on a linked service.