Skip to content

Update and expand guidance for paging current and upcoming on-call folks

Why is this change being made?

I noticed a a few inconsistencies/incorrect parts in this section, so I gave it a little overhaul to hopefully make it even easier/straightforward for people needing this information.

Note that this doesn't really change any existing processes – it just reorders information, updates links and adds clarity. The only thing that could be considered a change is explicitly saying to page after ten minutes without response on Slack, which was previously unspecified.

Here's the what and why:

  • I changed the order of linked PD schedules from alphabetical to align with their order across timezones, hopefully that makes it easier to orient oneself and identify where to look when an upcoming person is the goal
  • The sentence Tag the Support Manager On-Call by name in Slack to page the on-call manager was simply incorrect and removed – you can't page by doing a Slack ping
  • The section Paging the next on-call engineer was misleading: It technically described how to page the current on-call engineer. Added wording to clarify, plus guidance for when you actually need the next (i.e.upcoming) one.
  • Similarly, added more guidance on how to determine the upcoming on-call manager.
  • Added link to https://gitlab-com.gitlab.io/support/team/oncall.html resource
  • Made Ask in #support_leadership option more inviting
  • Added /pd trigger alternative method to page the current on-call person
  • Dropped important and urgent qualifier – from experience we can assume that people won't be too trigger-happy. We can adjust if that changes.
  • Added "holiday" to "weekend", as that's also when folks traditionally are only reachable via page when on-call
  • Added clear guidance to escalate to paging ten minutes after a Slack ping to avoid delays in critical situations
  • Removed /chatops run oncall references due to chatops oncall fails to run (gitlab-com/gl-infra/production-engineering#24925 - closed)

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
  • Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
    • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
    • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
    • The when to get approval handbook section explains the workflow in more detail
  • For transparency, share this MR with the audience that will be impacted.
    • Team: For changes that affect your direct team, share in your group Slack channel
    • Department: If the update affects your department, share the MR in your department Slack channel
    • Division: If the update affects your division, share the MR in your division Slack channel
    • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR

Commits

  • Update and expand guidance for paging current and upcoming on-call folks

Edited by Manuel Grabowski

Merge request reports