Escalation Policies and Severities
Understand how escalation steps, contacts, repeat rules, and severity alert channels work
Escalation policies decide who MonitoringDog notifies during an incident. Severities decide which notification channels are used when a policy step runs.
Use policies to model the response order. Use severities to model urgency.
Policies run step by step
An escalation policy contains one or more steps. Each step has:
| Part | What it controls |
|---|---|
| Delay | How long MonitoringDog waits before running the step |
| Contacts | Who MonitoringDog alerts at that step |
| Severity | Which notification channels the step uses |
MonitoringDog runs steps in order. If the incident remains active and unhandled, later steps can notify broader or more urgent responders.
Contacts decide who receives the alert
An escalation step can alert different contact types.
| Contact type | Use when |
|---|---|
| Current on-call person | The schedule should decide who is responsible at that time |
| Entire team | Everyone in the team should receive the alert |
| Team member | One specific member should receive the alert |
Use On-Call Schedules when the responder should change over time without editing the escalation policy.
Severities decide how alerts are sent
A severity is a named set of alert channels. The escalation policy references a severity in each step.
| Channel | What it does |
|---|---|
| Sends an email notification | |
| Push notification | Sends a mobile push notification |
| Integrations | Sends incident notifications to connected integrations |
Repeat rules rerun the policy
The repeat rule controls what happens if nobody acknowledges the incident.
| Setting | What it changes |
|---|---|
| Repeat count | How many times MonitoringDog repeats the policy |
| Repeat delay | How long MonitoringDog waits before repeating |
Use repeat rules for incidents that must keep paging until a responder acknowledges them.
Policies are used by monitoring resources
Checks and custom incident services use escalation policies when they create incidents.
Changing a policy affects future escalation behavior for resources that use the policy. Review dependent checks and custom incidents before changing a policy that is already in use.