Escalation Policies
Each service in Zenduty is mapped to an escalation policy. Escalation policies dictate how an incident created within a service escalates within your team.
Schedules on Zenduty enables your teams to ensure that dedicated support team members are available to resolve any issues as they arise. On-Call Scheduling provides the ability to set up on-call schedules, rotations, and escalation policies allowing 24x7 support coverage to be provided based on business needs. On-call scheduling also helps you to determine who is the current primary contact for a task, and to escalate notifications for a group.
Escalation policies can comprise of both on-call schedules and individual users. For example you can have an escalation policy E
where the first person to be notified is whoever is on call in schedule S1
. If the on-call for S1
does not respond to the incident(by acknowledging the incident) within 5 minutes, the escalation policy can escalate it to the backup schedule S2
. If the person(s) in S2
don’t acknowledge the incident within 10 minutes, then you can escalate it to the engineering manager, and so on.
If no one is in the escalation cycle, Zenduty will create the incident, but the Assignee will be blank. However, after a certain number of non-assignee incidents for the same integration, Zenduty will disable the integration, post which you will have to manually enable it.
Each service in a Zenduty team is governed by an Escalation Policy. This Escalation policy combines various schedules and tasks to be performed for the users in the team as a set of rules. When an incident is triggered in the service, alerts are triggered according to the Escalation Policy specified.
To view Escalation Policies of a Team, open the Teams section from the side bar and click on the team you want to expand. On the secondary header, select the tab Escalation Policies.
A list of all the Escalation Policies in a team will be visible to you.
Adding a New Escalation Policy
-
To create a new escalation policy, simply click the Create Escalation Policy button as shown above.
-
Give the escalation policy a name and summary.
-
To create Escalation Rules, keep the following in mind:
-
You can pick who to notify when an incident is created. It can be specific people, or the person on call from your team's schedule or a combination of them.
-
You can pick when someone else should be notified. For eg: the Team Lead can automatically be notified 15 minutes later. This is shown below:
- How each person is notified depends on the notification rules they or their team managers/admins have set up.
-
-
To put your escalation chain in a loop, change the Repeat Escalation Cycle value and add the number of time you'd like to run the escalation chain in a loop.
-
By default, Zenduty moves to the next escalation rule if the current rule(which only has a single on-call schedule) has no user on-call. To stop Zenduty from automatically moving to the next rule, unselect/deactivate the Move to next rule if no user found in current rule slider option.
Editing an Escalation Policy:
Click on the Escalation policy you'd like to make changes to, edit the configurations as desired and click on Save.
Deleting an Escalation Policy:
To delete an Escalation Policy, click on the Delete button next to the corresponding policy, and confirm.
Important - When a service or incident in a team, for instance Team B, is mapped to an escalation policy E
in another team, say Team A, the team admins or owners must ensure that all the users that fall within escalation policy E
are members of Team B. If a user that falls within escalation policy E
is not a member of Team B, then the member will receive the incident alerts on SMS, Phone, Email, Slack, Teams, Android/iOS push but will not be able to read the incident or update the incident.