Incident Management

When a monitor breaks, five things have to happen:

1. An incident is opened that records what’s broken and when.
2. Someone is identified as the on-call responder.
3. They’re paged through their preferred contact methods.
4. If they don’t ack, the page escalates to the next person.
5. No one gets paged for known maintenance.

Site Qwality’s incident management module wires these together. You can also use any of them on its own: incidents without on-call, manual incidents with no monitors, notification channels with no on-call schedule.

The building blocks

Incidents Record + timeline of an outage. Auto-opened by monitors of a service in auto mode, or created manually for non-monitor events.

Services Group monitors, pick the escalation policy, and decide whether failures open incidents.

On-call schedules Layered rotations in each schedule's timezone, with overrides for holidays and handoffs.

Escalation policies Ordered list of who to page next if no one acknowledges, with timeouts.

Notifications Channels (email, SMS, Slack, Teams, Discord, Telegram, webhooks) and groups, plus per-user contact methods.

Maintenance windows Silence specific monitors during planned work. One-time or recurring.

How they fit together

Monitor alerts                        Incidents

┌──────────────────────┐              ┌──────────────────────────────┐
│ Monitor flips status │              │ Monitor linked to a service  │
└──────────┬───────────┘              │ in auto mode fails, or you   │
           │                          │ open an incident by hand     │
           ▼                          └──────────────┬───────────────┘
┌──────────────────────┐                             │
│ Notification groups  │                             ▼
│ (account-level)      │              ┌──────────────────────────────┐
│ channels: email,     │              │ Service's escalation policy  │
│ Slack, webhooks, ... │              │ targets: users + schedules   │
└──────────────────────┘              └──────────────┬───────────────┘
                                                     │
                                                     ▼
                                      ┌──────────────────────────────┐
                                      │ User contact methods         │
                                      │ (email, SMS, Slack DM)       │
                                      │ × notification rules         │
                                      └──────────────────────────────┘

The two paths are separate: a monitor alert goes to the monitor’s notification groups whether or not an incident opens, and an incident pages people only through its service’s escalation policy.

Notification groups are account-level and set where a monitor’s alerts go. Contact methods and rules are per-user and set how each person is reached. The team configures routing once, and each engineer sets their own delivery preferences.

Manage it over the /v1 API

Resource	Routes
Services	GET and POST /v1/services; GET, PATCH and DELETE on /v1/services/{id}
Escalation policies	GET and POST /v1/escalation-policies; GET, PATCH and DELETE on /v1/escalation-policies/{id}; GET and POST /v1/escalation-policies/{id}/levels; POST /v1/escalation-policies/{id}/levels/reorder; DELETE /v1/escalation-policies/{id}/levels/{level_id}
Incidents	GET and POST /v1/incidents; GET, PATCH and DELETE on /v1/incidents/{id}; POST /v1/incidents/{id}/acknowledge, /resolve, /reopen and /updates

curl "https://api.siteqwality.com/v1/incidents?status=active" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY"

• They take the same fields as /service, /escalation_policy and /incident, and answer in the /v1 shapes: lists newest first as {"data": [...], "next_cursor": "..."}, one resource as the object itself, errors as application/problem+json. Idempotency-Key works on every POST and PATCH.
• Policies in a list carry their levels. Incidents in a list carry their updates; read one incident for its monitors and participants. status filters the incident list: active, resolved or all (the default).
• PATCH changes only the fields you send. DELETE answers 204, also when the resource is already gone.
• POST /v1/incidents/{id}/acknowledge takes an empty body from a signed-in user. An API key or client sends {"acknowledged_by": "<user id>"}.
• Services need read:services and write:services; incidents and escalation policies need read:incidents and write:incidents.
• Service monitors, notification targets, incident participants, postmortems, action items and on-call schedules stay on the older routes for now.

When NOT to use this

• Don’t page for transient flakes. Raise the monitor’s confirmation settings so a single failed check does not count as down. A notification group’s send delay holds back the monitor alert (HTTP monitors, heartbeats and browser checks), but it does not stop an incident from opening. See Notification groups.
• Don’t escalate everything. Reserve escalation policies for high-urgency incidents. For warnings, a single Slack channel notification is enough.
• Don’t put your CTO on every escalation policy. Build escalation chains with clear ownership: primary on-call → secondary → engineering manager.

See also

• Status pages: publish incidents externally.
• Integrations: connect Slack, Teams, Discord, Telegram, webhooks.