Understand escalation policies

Understand the policy model

• A policy has one to five ordered steps. Each step defines a notification channel, recipients, a delay, and optional repeat settings.
• delayMinutes is measured from the start of the incident. A value of 0 makes the step due when the incident opens.
• repeatIntervalMinutes and maxRepeats describe how often a sent step may be sent again before the incident is acknowledged.
• The policy must be active and assigned to a monitor before it can route that monitor's alerts.

Follow the alert path

1. A monitor opens an incident. The monitor has an active escalation policy assigned to it.
2. Due steps are evaluated. A step is due when its delay has elapsed and it has not reached its repeat limit.
3. A notification is dispatched. The selected channel receives the alert when that channel has a working transport.
4. Acknowledgement stops escalation. Acknowledged or resolved incidents no longer produce due escalation steps.

Know which channels deliver

• Email. Email steps can send to the comma-separated addresses in the step.
• Webhook. Webhook steps can send to an HTTP or HTTPS endpoint.
• SMS and Voice Call. These options appear in the policy builder, but their escalation transports are not implemented and do not deliver notifications today.

PagerDuty has a separate integration and is documented in the PagerDuty integration article. It is not currently a selectable channel in the escalation policy builder.

Keep acknowledgement in the loop

Escalation is intended for alerts that remain unacknowledged. A responder who acknowledges the incident prevents later due steps from dispatching. Recovery notifications are configured separately from escalation policies.

Related

• Build a multi-step escalation policy
• Assign a policy to a monitor
• How alerting works