Not every alert should go to the same person forever. Escalation lets an unresolved alert automatically reach a wider or more senior audience the longer it stays unacknowledged, instead of relying on the first notified person to always catch it.
How escalation works
An escalation is built from levels, each with its own contact group and a time delay before it activates. A typical pattern:
- Level 1 (immediate) — notify the on-call team as soon as the alert fires
- Level 2 (after 15–30 minutes unresolved) — notify a senior engineer or team lead if it's still not acknowledged
- Level 3 (after a longer delay) — notify management, for anything that's become a sustained outage
Each level uses the same Contact Groups and Time Periods set up under Administration, so escalation is really just a sequence of "who, and when" rules layered on top of a single alert.
Setting up a host escalation
- Open the host (or service) you want escalation on.
- Add an escalation definition, specifying the contact group and the delay before each level activates.
- Order levels from fastest response to broadest audience.
- Save, and confirm the escalation appears alongside the host's regular alert configuration.
What deserves escalation
Reserve multi-level escalation for infrastructure where a prolonged outage genuinely matters — core network equipment, production databases, customer-facing services. Applying it everywhere just means more people getting paged for things that were never that urgent in the first place, which erodes trust in the alerting system faster than almost anything else.
Acknowledging an alert (having someone mark it as being handled) is usually what stops escalation from continuing to the next level — see Email Notifications for how acknowledgement interacts with repeat notifications.