How to schedule users as unavailable? Easier management of "Time-Dependent" groups.


(Sean Roberts) #1

We have a team distributed across many time zones and have found that “Time-Dependent Group Notifications” is the only PagerDuty method that works for us.

How it works:

  • Each user has their own PD Schedule configure to their “business/working hours”.
  • All of those schedules are at the 1st layer of the Escalation Policy.
  • Typically we have 3+ users available at any time.
  • 2nd layer of Escalation Policy is the official On-Call engineer for the week.

But what if a user is not available?

2 problems:

  1. Have to override that users personal schedule with another user. That won’t work as that other user will have different working hours. And they may also be unavailable.
  2. I would need to override each instance. Over 2 weeks, that is a lot of manual overrides.

At this time, our only option is:

  • Remove the users schedule from the escalation policy, and then remember to add it back when they return.

Simple features to solve problem “1” above:

  • Ability to assign an override to “Skip/None/…” instead of only to specific people.

Better feature which would solve many problems and likely win more PagerDuty customers/deals:

  • “Dynamic Schedule”: Ability to have a specific schedule which is tied to users “availability”.
    • Availability could be an “opt/clock-in” when they are available, or tied to API, such as to Slack availability or a phone system.
    • This would not affect existing manually managed schedules, and you’d put the next layer in the “Escalation Policy” to ensure the incident is caught if no one is “available”.
    • This is fairly standard practice in teams to ensure coverage of queue/monitoring-dashboards/phones and to make sure someone is in over lunch breaks, shift handovers, …
    • Extra: PD could ask users if they are available. So no one forgets to clock-in. (When it’s not tied to API/Availability).

Another feature:

  • Ability to mark a user as a way.
    • Essentially removing them from the schedule and escalation policies for that period of time.
    • If no other users are at that layer of the schedule or escalation policy, then it should automatically go to the next layer.