Escalation Policies
Build the chain of people and teams who get notified, in order, when an incident isn't acknowledged.
An escalation policy answers one question: if nobody responds, who gets notified next? For example: On-Call Engineer → Team Lead → Director. Ionhour builds this visually — you add a level, choose who's on it, and set how long to wait before moving to the next one.
Policies, Routing, and Channels are three different things
It's easy to mix these up, so here's the split:
- Escalation Policies (this page) decide WHO ultimately gets notified, in what order.
- Alert Routing decides WHICH policy gets triggered for a given alert — i.e., when an incident happens, routing picks the matching policy.
- Channels decide HOW a notification is delivered — Slack, email, SMS, and so on.
Think of it as: Alert Routing picks the policy → the policy decides who's notified and when → Channels deliver the message to them.
The Policies List
Open Escalation Policies from the On-Call section of the sidebar to see every policy in your workspace: its name, which projects it applies to, a quick preview of its levels, and whether it's active or disabled. Use the All / Active / Disabled tabs and the search box to narrow the list, and click any row to open it in the builder.
If you don't have any policies yet, you'll see a quick-start prompt — just give your first policy a name and continue straight into the builder.
Building a Policy
Click Create Policy (or open an existing one) to enter the visual builder. It's split into two parts: a settings panel on the left, and the escalation flow diagram on the right.
Policy Settings
| Setting | Description |
|---|---|
| Name | A label so you can recognize the policy in the list, e.g. "Critical Alerts" |
| Projects | Which projects this policy applies to. Leave empty to apply it to all projects. |
| Ack timeout | Optional. If someone acknowledges an incident but never resolves it within this many minutes, the acknowledgment is cleared and the policy resumes escalating from the next level that hasn't fired yet (not from the top). As a safety net, this can happen at most 3 times per incident, so a policy can never re-escalate forever. |
| Enabled | Turn the policy on or off. Disabled policies won't trigger. |
The Flow Diagram
The diagram shows your escalation as a straight chain:
Incident triggers this policy → Level 1 → Level 2 → ... → End
Each level is a card where you configure:
- Wait time — how long to wait after the previous level before this one fires (e.g. "Don't wait", 5 minutes, 10 minutes, 15 minutes, or a custom number of minutes). The very first level always fires immediately.
- Who gets notified — add one or more targets to a level: a specific person, a whole team, an on-call schedule (notifies whoever is currently on duty), or an alert channel. You can combine several on the same level — for example, notify the on-call engineer and post to a Slack channel at the same time.
- Conditions (optional) — restrict a level to only fire during certain days of the week and time windows, in a chosen timezone. Leave it unset and the level fires at any time.
Click the small + button on the connecting line between two levels to insert a new level in between, or use the menu on a level's card to delete it.
Name Your Policy
Give the policy a clear name and, if it should only apply to certain projects, select them. Leave projects empty for a catch-all policy that applies everywhere.
Add Your First Level
The first level fires the moment an incident opens, so it can't have a wait time. Add whoever should hear about it first — usually an on-call schedule so the current on-duty person is always covered, not a specific hardcoded name.
Add More Levels As Needed
Click the + button on the line below a level to insert the next one. Choose a wait time (how long to give the previous level a chance to respond) and add its targets — a team, a manager, a different alert channel, anything that makes sense for how urgent things should get.
Save
Once every level has at least one target, save the policy. It's now live and will apply to any matching incident going forward.
While editing an existing policy, use Dry run to preview exactly when each level would fire for a hypothetical incident — without actually notifying anyone. It's a safe way to sanity-check wait times and targets before relying on the policy for real.
Best Practices
- Always start with an immediate level. Someone should know about an incident the instant it happens — don't make level 1 wait.
- Point at schedules, not people. Targeting an on-call schedule instead of a specific person means the right person is always covered, even during handoffs or time off.
- Space levels out sensibly. A few minutes apart is usually enough to give someone a fair chance to respond without letting things go quiet for too long.
- Keep it short. Two or three levels covers most teams. If you find yourself needing many more, it's often a sign the underlying response process needs attention, not the policy.
- Use Dry run before trusting a new policy. Confirm the order, wait times, and targets look right before it handles a real incident.