- Steps with a delay each, set per contact
- Acknowledging the incident stops later steps
- A second Telegram or email contact as the last resort
- Steps are skipped if the incident has already recovered
Other features
The idea in one sentence
An escalation policy is a list of contacts, each with a delay, that all hang off the same incident: the first person hears immediately, the next only if the incident is still unacknowledged after their delay, and so on. It is a Pro and Agency feature, because it is the point at which a monitoring tool stops being a notification and starts being a safety net. Under the hood each step is a contact plus a number of seconds, and the alert is queued for that time rather than sent at once.
A timeline you can copy
Here is a policy for a store whose owner sleeps with the phone on silent, and a freelancer who looks after the technical side. Times are measured from the moment the incident opens, which is after multi-region confirmation, not from the first failed check.
- Immediately: Telegram message to the team group, plus an email to the support address.
- After 5 minutes unacknowledged: email to whoever is on duty that week.
- After 15 minutes unacknowledged: Telegram message to the owner’s personal chat, the one that is allowed to make noise at night.
What the timeline looks like in practice
The site starts returning errors at 02:13:40. By 02:14:10 the failure is confirmed, the incident opens and the Telegram message and email go out. Nobody reacts. At 02:19:10 the email reaches the on-duty person, who taps the acknowledge link from bed. The incident is now acknowledged, so the 15-minute Telegram message to the owner is skipped when it comes due, and the owner is never woken up. The site recovers at 02:41 and everyone who received something gets a recovery message with the downtime duration of 26 minutes and 50 seconds.
If nobody had acknowledged, the message would have gone to the owner at 02:29:10. And if the site had recovered at 02:17 before the email was due, the email would also have been skipped, because queued steps are dropped when the incident is already resolved.
What stops the chain
Acknowledging stops it: from the incident page, the email link, the API, or /ack in Telegram. Resolution stops it too. A recovery always reaches the contacts that were told about the problem. What does not stop it is a quiet hour; those delay only non-critical notices such as certificate warnings and slow-response alerts, never downtime. Quiet hours therefore cannot make a night page vanish.
Cost and caps
Escalation steps cost nothing extra: every step is Telegram or email, so there are no per-message charges and no allowance to run out. Steps do count towards the hourly alert cap, which is 1,500 on Pro and 6,000 on Agency and only matters in a real storm. Put chains on the monitors where an hour of downtime really costs money, and leave everything else on a single immediate alert.
Mistakes that make escalation useless
The common ones are boring. Everyone in the chain is the same person, so the message after fifteen minutes lands on the same phone that ignored the email. The final step is a contact that has not been verified, so it silently does nothing. A noisy monitor has a chain attached and trains everyone to ignore it, so nobody reacts to the real outage. And the policy is attached to the wrong monitors, so the one site that matters still alerts a single email address. Review the chain whenever someone joins or leaves the team.
Designing delays that people can live with
A delay shorter than the time a human needs to read a notification is just noise. Five minutes is a reasonable first gap for a site where an outage is bad but not catastrophic; two or three minutes suits a payment page. Make the last step slightly less polite than the first: send it to the personal chat that is allowed to make noise at night. Test the whole chain once with a throwaway monitor pointed at a URL you control, so the first time you meet the policy is not a real incident.
Escalation here is deliberately simple. There are no rotating on-call calendars, no overrides for holidays and no follow-the-sun routing. If you need those, send alerts to PagerDuty on Agency and let it page the right person. For fine detail on the commands and contact types, see alerts and escalation in the docs, and for the incident side, incident management.
Questions
Which plans include alert escalation?
Pro and Agency. Starter and Free alert every contact straight away, with no delay between steps.
Does acknowledging cancel the recovery message?
No. It cancels the later escalation steps. The people who already heard about the incident still receive a recovery message when the site is back.
Are delays measured from the first failed check?
From the moment the incident opens, which is when the failure has been confirmed by the other regions. Confirmation takes up to about a minute by default, so the first step is not instantaneous.
Can I escalate to a different person per client?
Yes. The delay belongs to the contact and each monitor chooses its own contacts, so a different chain per client means different contacts on that client’s monitors. On Agency, client workspaces also have their own default contacts.
Start monitoring in two minutes
30 monitors free, forever. No credit card. Moving from UptimeRobot? Import your monitors in one click with a read-only API key.