Overview

Most businesses are becoming tech companies meaning they have a SaaS service that they provide to their customers. SaaS services do not get "turned off" at the end of the business day - customers expect 24/7 reliable availability. This means that when things go wrong, companies need to have a team (or multiple!) that can quickly and effectively respond to service outages.

Being the person responsible for helping to restore service outage is being on-call. When a team member is on call, they need to be available around the clock. This is a stressful job. To manage stress and burn-out, most companies have a team of responders that take turns being on-call. This requires on-call calendar management tools that allow these teams to create and modify on-call schedules according to their specific rotations.

On-call Schedule Management is a table-stake of an Incident Management tool.

Strategy

We need to establish the schedules and escalations in GitLab. Adding these at the group level allows users to organize their services and alerting endpoints by project. We believe this is the right level to organize schedules and escalation policies because responding teams typically have a 1:Many relationship with projects or services. Projects, which contain the code for individual services and the integrations for alerts on those services, reside in a group. When an alert comes a GitLab project, the alert is routed to the on-call responder as defined by the on-call schedule for the sub-group.

• Use groups as "teams" in GitLab
• Establish on-call schedules and escalation policies at the group level
• On-call schedules are made up of rotations and scheduled overrides
• Alerts are sent via webhook to GitLab and received in projects where they are then routed to the on-call responder in the schedule in the escalation policy that is mapped to the project

MVC

TBD

Leverage existing GitLab components such as the calendar used in Roadmaps.