Round-Robin - Feedback & oddities

We Love the Round-Robin feature, and use it to distribute the incoming events, across the multiple schedules we have in a 7 day period. All schedules are part of a single EP Step at a time, however not all schedules are manned at once, so some Schedules are “blank” from a support perspective until that particular on-call period is reached. This causes a few minor quirks in regards to round-robin :

1. When viewing the EP, you visually see with the green arrow what the next schedule to receive the event is, however if the schedule is empty at that moment of time, the “next-in-line” indicator remains “stuck” on that schedule until eventually that schedule is manned and receives an event. This causes no issues for the actual events received, who will go to the next available schedule correctly, but the visual aspect of it is broken.
a. Solutions :
i. Indicator should show the actual next in line non-blank schedule, and not be stuck on a blank (the logic is already there somewhere)

2. In the case where there are three schedules, for three different people on-duty normally manned (Joe,Jane,Marc) and Marc goes on vacation
a. Because there are no “block-out” capabilities, an overwrite is done on Marc’s schedule to be replaced by Joe
b. Visually in the EP, you will see Joe and Jane in the EP Step and Marc’s schedule will appear blank in the EP, as Joe is on two schedules (his own + override Marc’s)
c. However, for the round-robin, the “Event-support queue” will be as follows : Joe,Jane,Joe

i. Solutions :

  1. Ensure a name in the EP step is shown on all schedulesa member is online for
  2. Across a same EP step, establish the “event-support-queue” across all “Unique member’s” part of that escalation step
1 Like

Hey there,

Thanks for submitting this community post.

When a schedule is due for assignment next, PagerDuty attempts to assign the incident to whoever is currently on call on that schedule. In cases where no one is on call, due to a coverage gap, for example, PagerDuty will skip the schedule and assign the incident to the next user or schedule in the assignment ring. This ensures that a coverage gap on a schedule does not cause an incident to be missed.

When this skip due to a coverage gap happens, the schedule will remain at the front of the assignment ring, and PagerDuty will attempt to assign the next incident to it.

If this is not in line with the behavior you are seeing, we can certainly investigate this for you. We’d need to obtain some information from you so it’d be best to reach out to support@pagerduty.com so we can get that information privately rather than here on this public forum.

If you’d like us to look into this, please provide some example events that seem to have been dropped due to the schedule being empty at the time of the event being sent to PagerDuty.

Hope to hear from you soon.

-Ryan