Your site goes down. The first person on call doesn't see the alert — they're in a meeting, their phone is off, or the notification never arrived. Without escalation, the incident can sit unacknowledged until a customer complains.
An escalation policy defines what happens when no one responds: after X minutes, notify the next person (or the next level). It turns "we hope someone sees it" into "someone will be paged until the incident is acknowledged." This guide covers why escalation matters, how to design a policy, and what to look for in a tool.
Why Escalation Matters
Alerts get missed
People sleep, travel, or step away. A single notification to one person is not enough for critical incidents. If that person doesn't acknowledge or respond within a set time, someone else should be notified.
One person shouldn't be the single point of failure
When only one contact gets the alert, the system is fragile. Escalation adds a second (and optionally third) level so that if the first responder is unavailable, the next one is paged. Incidents get picked up instead of falling through the cracks.
You get a record of who responded
Good escalation tools record who was notified, when, and whether they acknowledged. That helps with post-incident review ("why did it take 20 minutes?") and with improving response times and schedules.
How Escalation Works
A typical escalation policy has steps:
- Step 1 — Notify the first group (e.g. the current on-call person). Wait for acknowledgment or for a timeout (e.g. 5 minutes).
- Step 2 — If no acknowledgment within the timeout, notify the next group (e.g. second on-call, or team lead). Again, wait for acknowledgment or another timeout.
- Step 3 (optional) — If still no acknowledgment, notify a final group (e.g. entire team, or manager).
So: notify → wait → if no ack, escalate to next → repeat. The incident is "acknowledged" when someone explicitly acknowledges it (e.g. in the tool or by clicking a link). Until then, escalation continues.
What to Put in an Escalation Policy
Steps and order
Define the order of notification: who gets tried first, second, third. Often:
- Level 1 — Primary on-call (from your on-call schedule).
- Level 2 — Secondary on-call or backup person.
- Level 3 — Team lead, manager, or "everyone" as a last resort.
You can have 2–4 steps; more than that often adds delay without much benefit.
Timeouts (delay between steps)
How long to wait before escalating? Too short and you wake everyone up; too long and the incident sits unacknowledged.
Common choices:
- 3–5 minutes — For critical (e.g. full outage). Fast escalation.
- 10–15 minutes — For high-priority but not life-threatening.
- 30+ minutes — For lower-priority or follow-the-sun where you're giving the primary region time to respond.
Use different policies (or different timeouts) for different severity levels if your tool supports it.
Who is in each step
Each step can be:
- One person — e.g. current on-call from a schedule.
- Several people — e.g. "notify Alice and Bob; if either acknowledges, stop."
- A schedule — "notify the current on-call user for Schedule A; if no ack, notify Schedule B (backup)."
Linking escalation to your on-call schedule means you don't update the policy every time the rotation changes; the right person is always level 1.
Repeat or stop
Some tools let you repeat the policy (e.g. loop back to step 1 after step 3) until someone acknowledges. Others stop after the last step. Repeating can help for 24/7 coverage so the same people get re-notified; define whether you want that and how often.
Escalation and On-Call Schedules
Escalation becomes much simpler when it's schedule-aware:
- Level 1 — Current on-call user (from your rotation). No manual change when the rotation advances.
- Level 2 — Next in rotation, or a dedicated backup schedule, or a fixed person (e.g. team lead).
- Level 3 — Broader group or manager.
When the tool resolves "who is on call" from the schedule, you get correct escalation without editing the policy every week.
Best Practices for Escalation Policies
Don't escalate too fast
3–5 minutes is often enough for someone to see a page and acknowledge. Escalating after 30 seconds can cause multiple people to wake up for the same incident. Balance speed with giving the first responder a real chance to respond.
Make acknowledgment easy
The first responder should be able to acknowledge with one click (e.g. in an email link or in the tool). If acknowledgment is hard or unclear, people won't do it and escalation will fire every time.
Different policies for different severities (optional)
If you have critical vs high vs low severity, you can use:
- Critical — Short timeout (e.g. 5 min), escalate to backup then lead.
- High — Longer timeout (e.g. 15 min), maybe only two steps.
- Low — Email only, no escalation, or long timeout.
Not every tool supports this; start with one policy for "all production incidents" and split by severity later if needed.
Document and test
Document which monitors or alert types use which escalation policy. Once per quarter, run a test escalation (or use the tool's "test" feature) to confirm the right people get notified in the right order and that acknowledgment stops escalation.
What to Look For in an Escalation Tool
When evaluating a tool (or the escalation feature in your monitoring platform), check:
- Multiple steps — At least 2–3 steps with configurable order.
- Configurable timeouts — Delay between steps (e.g. 5, 10, 15 minutes).
- Schedule integration — Level 1 (and optionally level 2) can be "current on-call user" from a schedule, so you don't edit the policy when the rotation changes.
- Acknowledgment — Clear way for the user to acknowledge; escalation stops when someone does.
- Channels — Notify via email, SMS, Slack, or other channels so the right person is reached.
- Audit — Who was notified, when, and whether they acknowledged (for post-incident and tuning).
Tools that combine monitoring, on-call schedules, and escalation in one product (e.g. Webalert Business) keep everything in sync: monitor down → incident created → escalation policy runs → right person is paged.
How Webalert Handles Escalation
Webalert's escalation policies (Business plan) let you:
- Define steps — Add multiple steps with configurable delay (e.g. 5 min, 15 min) between each.
- Use on-call schedules — A step can notify the current on-call user from a schedule, so rotation changes don't require policy edits.
- Add backup levels — Next step can be another schedule, a user, or a channel (e.g. #incidents).
- Acknowledge — Responders can acknowledge from the notification (e.g. link in email or in-app); escalation stops when the incident is acknowledged.
- Connect to monitors — Link monitors (or groups) to an escalation policy so when a monitor fails, the policy runs and the right people are paged in order.
Together with on-call schedules, you get: the right person on call, and if they don't respond, the next person is notified automatically. See features for escalation and on-call details and pricing for the Business plan.
Quick Checklist: Escalation Policy
- Define 2–3 steps (who is notified first, second, third).
- Set timeouts (e.g. 5 min, 15 min) so the first responder has time to ack.
- Tie level 1 (and optionally level 2) to your on-call schedule if the tool supports it.
- Ensure acknowledgment is easy and that escalation stops when someone acks.
- Link the policy to the right monitors or alert types.
- Test the policy (test notification or drill) and document who gets notified when.
Final Thoughts
Escalation turns "we sent one alert" into "we keep notifying until someone responds." Define clear steps, sensible timeouts, and who is in each level — ideally using your on-call schedule for level 1 — and wire your critical alerts to an escalation policy. You'll cut down on missed incidents and avoid single points of failure.
Escalation and on-call in one place
See Webalert escalation and on-call →
Check features and pricing. Business plan with on-call add-on.