Default wait between steps?

5 minutes for Critical production paths. Medium/internal: 10–15 minutes. Review quarterly.

Notify one or notify all?

Schedules: notify one. Team step when anyone available should see the page immediately: notify all.

Schedules vs policies?

Schedules = who is on call when. Policies = who to page and in what order when an incident needs a human.

Preview or copy each section below. Paste into Notion, Confluence, or your wiki.

Policy design

Escalation policy: [Name]

Acknowledgement stops the chain. Unacked pages advance after the wait.

Policy card

Field	Value
Policy key	[stable-key]
Owner	[Team]
Reviewed	YYYY-MM-DD

Auto-routing (optional)

Triggers: Incident created · Incident updated

Match	Value
Severity	Critical, High
Components	[API, Payments]
Tags	production
Teams	[Platform]

Leave empty for a catch-all. Split policies by severity to reduce alert fatigue.

Steps

#	Target	Strategy	Wait	Notes
1	Schedule: [Primary]	Notify one	5 min	Current on-call
2	Schedule: [Secondary]	Notify one	5 min	Backup
3	Team: [Platform]	Notify all	10 min	Any responder
4	User: [Director]	Notify one	—	Final human

Targets: On-call schedule · Team · User

Strategy: Notify one = round-robin · Notify all = parallel (first ack wins)

Reference designs

Production Critical Primary schedule (5m) → Secondary schedule (5m) → Team notify-all (10m)

Business-hours Medium Match: Medium + tag business-hours → Primary schedule (15m) → stop

Mid-incident

Use Bring in to add a user, team, or schedule without editing this policy.

Test before prod

Staging incident triggers correct policy
Shift verification on for schedules
Critical matches here; Low does not
Waits feel right with real ack flow

Avoid

Single step, no timeout · Same policy for every severity · Final step is one person with no backup

# Escalation policy: [Name]

> Acknowledgement stops the chain. Unacked pages advance after the wait.

## Policy card
| Field | Value |
|-------|-------|
| Policy key | [stable-key] |
| Owner | [Team] |
| Reviewed | YYYY-MM-DD |

## Auto-routing (optional)
**Triggers:** Incident created · Incident updated

| Match | Value |
|-------|-------|
| Severity | Critical, High |
| Components | [API, Payments] |
| Tags | production |
| Teams | [Platform] |

*Leave empty for a catch-all. Split policies by severity to reduce alert fatigue.*

## Steps
| # | Target | Strategy | Wait | Notes |
|---|--------|----------|------|-------|
| 1 | Schedule: [Primary] | Notify one | 5 min | Current on-call |
| 2 | Schedule: [Secondary] | Notify one | 5 min | Backup |
| 3 | Team: [Platform] | Notify all | 10 min | Any responder |
| 4 | User: [Director] | Notify one | — | Final human |

**Targets:** On-call schedule · Team · User

**Strategy:** Notify one = round-robin · Notify all = parallel (first ack wins)

---

## Reference designs

**Production Critical**
Primary schedule (5m) → Secondary schedule (5m) → Team notify-all (10m)

**Business-hours Medium**
Match: Medium + tag `business-hours` → Primary schedule (15m) → stop

## Mid-incident
Use **Bring in** to add a user, team, or schedule without editing this policy.

## Test before prod
- [ ] Staging incident triggers correct policy
- [ ] Shift verification on for schedules
- [ ] Critical matches here; Low does not
- [ ] Waits feel right with real ack flow

## Avoid
Single step, no timeout · Same policy for every severity · Final step is one person with no backup

How to use this template

Start with one catch-all, then split by severity as volume grows.
Notify one for schedules; notify all for team-wide steps.
Name policies exactly as referenced in schedules and runbooks.

Incido policies support ordered steps, schedule/team/user targets, notify-one vs notify-all, step delays, and routing on incident create/update by severity, components, tags, and teams.

Explore on-call

Escalation Policy Designer