Follow-the-Sun Schedules


(Simon Fiddaman) #1

So you want a follow-the-sun response to your alerting?

Option 1: I want the best setup with the least overlap

  1. Create s Schedule, selecting UTC as the time zone because it doesn’t change.
  2. Start with any one of your regions
    1. Select the user(s) for this region
    2. Hit the Restrict on-call shifts to specific times checkmark
      1. If this is a 24x7 schedule, just the first times-of-day option and add your window in UTC (e.g. 06:00 - 20:00)
      2. If this schedule has gaps (like weekends), you’ll need the second option, creating additional blocks until you’ve reached your desired coverage.
      3. NOTE: If you end up with holes in your Schedule, alerts received during these holed times will be Suppressed (blackholed).
    3. Select your Rotation type and choose a Handoff time which matches the start of your natural blocks (e.g. Monday at 08:00 as per the example above)
  3. Repeat with any other region(s), adding a new Layer for each region
  4. Add the Schedule to an Escalation Policy (or multiple Policies if you have further unique escalation points, e.g. for SME On-calls).

NOTE: During Daylight Savings Time, for those locations which honour it, the local rostered times of those regions will change (i.e. 07:00 may become 08:00 during DST for one region), but the relative handover time between regions (i.e. complete coverage) will remain constant.

Option 2: I want consistent start-and-end times in all of my regions

This is not a good option, only because you need to ensure you have a wider shift handover period, and because due to the way the Escalation Policy (which is where you’ll be managing this) works, some shifts will end up shorter than others as DST differences change. It does have some advantages - especially if you have a single “main” region who should receive the brunt of the Incidents.

For this option, setup as many Schedules as you have Regions, as above, but populating only a single Layer, and setting the time zone to the region time zone.

Create an Escalation Policy. Here we can finalise this in two ways:

  1. Add all Schedules to a single Escalation Policy Level - everyone on shift at that moment will be assigned (and paged). This means during overlap periods there’ll be multiple (usually 2) assignees. This isn’t bad, you just need to manage the expectations here. When DST stretches the overlap to 0, it will transition cleanly between regions.
  2. Add each Schedule to a new Escalation Policy Level - this is probably better if you have one main region and the other regions are satellites. Note that Incidents will be assigned to the first populated (with an available assignee) Level, so put your “main” region first, next largest/best second, etc. The “main” region will always be assignable for their full hours allotment, regardless of DST changes, but each subsequent Level/region will shrink and grow as regional DST kicks on or off.

Final considerations

If you have multiple people on these shifts (e.g. a NOC) and you want more than one to be assigned/paged, duplicate the Schedules (as each Schedule will always result in a single result) and add them to their respective Escalation Policy Layers (note that this must be done in an Escalation Policy).

These schedules can be built programmatically using the Create an override API v2 call. It’s best to always have a default assignee (e.g. the Team Lead) as a base for all Schedule Layers in the event the programmatic Overrides ever fail.

Follow-the-sun embargo schedule