Sequential escalation levels
Add as many levels as your team needs. Each level has its own targets and timeout window. The policy advances automatically when an acknowledgment isn't received in time.
Escalation Policies
Keep escalating until
Keep escalating until
someone responds.
Define step-by-step policies that notify person A, wait, then notify person B or the current on-call responder, until someone acknowledges. Per-service policies, with configurable timeouts at every level.
Free tier included
No credit card
2-minute setup
An alert that doesn't give up.
Critical alerts don't stop after one attempt. An escalation policy works through its levels methodically. It notifies each target, waits for a configurable timeout, then moves on, until the incident is acknowledged or the policy repeats.
Per-level timeout control
Set the acknowledgment window independently for each level, from 1 minute to 24 hours: 5 minutes to the on-call engineer, then 10 minutes to the team lead, then the engineering manager.
Target users or schedules
Point any level at specific people, at on-call schedules, or both. When a schedule is targeted, the current on-call responder for that schedule is paged, whoever that is at the time.
Automatic re-escalation
Configure a repeat count, up to 20, so the entire policy restarts if all levels exhaust without acknowledgment.
Per-service assignment
Each service in your catalog can carry an escalation policy. Incidents on the payments service page the payments on-call; platform incidents page the platform team.
Responder status on the incident
The incident record shows whether it has been acknowledged or resolved. A per-level escalation history is not available today.
Nothing falls through the cracks
Step-by-step until
Step-by-step until
someone picks up.
Most alerting tools send a single notification and call it done. Escalation policies are different: they advance through levels automatically, accounting for silence, until the incident is acknowledged, or until the configured repeat limit is reached.
- Advances to the next level after an unacknowledged timeout
- Targets on-call schedules so no name is ever hardcoded
- Repeats the full policy if all levels exhaust unacknowledged
payments-svc policy Level 2 ActiveLIVE
LEVEL 1 TIMEOUT5m elapsed
LEVEL 2 TIMEOUT10m running
INCIDENTS THIS WEEK3
L1: on-call paged100ms
L1: timeout elapsed85ms
L2: lead paged70ms
L2: awaiting ack50ms
L3: manager (pending)20ms
Per-service, defined in your repo
One policy per service,
One policy per service,
provisioned by API.
Assign an escalation policy to every service in your catalog and provision them all via the REST API: create the policy, then add each level with its timeout and targets. Drop the calls into a script in your repo and pull requests show you exactly which routing changed.
- Each service points at the policy it should use
- Policies and levels created through the REST API
- Changes take effect immediately; no restart required
create an escalation policy$ curl -X POST https://api.siteqwality.com/escalation_policy \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Payments SLA Policy","repeat_count":2}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":5,"target_schedule_ids":["$PAYMENTS_ONCALL"]}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":10,"target_user_ids":["$PAYMENTS_LEAD"]}'
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Payments SLA Policy","repeat_count":2}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":5,"target_schedule_ids":["$PAYMENTS_ONCALL"]}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":10,"target_user_ids":["$PAYMENTS_LEAD"]}'
N+1
levels per policy, as many as your team needs
20
repeats of the whole policy at most, if nobody acknowledges
1m
minimum configurable timeout between escalation levels
$0
escalation policies on every plan; the free tier includes 1 responder
FAQ
There is no hard cap on the number of levels. In practice, most teams use two to four levels (on-call engineer, team lead, then a manager), but you can add as many as your operational requirements demand.
If a policy is configured with a repeat count greater than zero, it restarts from level one and works through the levels again. This continues until the repeat limit (at most 20) is reached or someone acknowledges the incident.
Yes, and this is the recommended approach. Point a level at an on-call schedule and Site Qwality determines who is currently on call at the time the level fires. You never need to update the policy when rotations change.
Escalation respects each team member's personal notification rules, which use email, SMS or a Slack direct message. If a responder has configured SMS for high-urgency incidents and email for low-urgency ones, that preference is honoured when the escalation policy pages them. A Slack direct message needs a Slack bot token pasted into the contact method.
Yes. Each service in your catalog can point at its own escalation policy. Payments can have a tight policy; an internal tool can have a relaxed one. Changes take effect immediately.
Yes, by hand. There is no Opsgenie importer, so you recreate each schedule and escalation policy and point every level at a schedule instead of a person. Atlassian will shut Opsgenie off on April 5, 2027. The Opsgenie alternative page walks through the migration and lists what Site Qwality does not have.
Related features
Start free. No credit card.
Uptime, cron, synthetic, logs, RUM, incidents, and status pages. Free tier on every product.