alerts.manage.
How escalation works
- The
alertrole checks active incidents every[alert].dispatch_interval_secs, 10 seconds by default. Only incidents with the statusopenadvance. Acknowledging an incident stops escalation. - A step with
min_severityapplies only to incidents of that severity or higher. Steps that do not apply are skipped. - Every target of the current step receives a notification event. Notification channels decide how the message is delivered. The
assigneesof the incident become the users that the step names directly: itsusertargets and the on-call user of eachscheduletarget. A step that targets only teams keeps the earlier assignees. - When
ack_timeout_secspasses without an acknowledgement, the next applicable step starts. - After the last applicable step times out, a policy with
repeatset totruestarts again at the first step untilmax_loopspasses are complete.
escalation_policy_id. A rule without one uses default, an alias for the policy of the organization whose name is default, compared without regard to case. When escalation starts, the incident stores the real id of that policy, so renaming the policy later does not move an open incident to another policy. When the organization has no policy named default, the incidents of such a rule never escalate, although the triggered event still reaches notification policies. Create a policy named default, or point the rule at a policy id.
Body
A step has these fields:
A target selects its recipients with
kind:
The call does not check that the referenced user, team, or schedule exists.
Other policy routes
PUT takes the body of the create call and replaces the policy. DELETE answers the plain text deleted, and an unknown id answers 404. Deleting a policy does not check the rules that reference it. Those rules stop escalating.