If you're a GitLab team member and are looking to alert Reliability Engineering about an availability issue with GitLab.com, please find quick instructions to report an incident here: Reporting an Incident.
If you're a GitLab team member looking for who is currently the Engineer On Call (EOC), please see the Who is the Current EOC? section.
If you're a GitLab team member looking for the status of a recent incident, please see the incident board. For detailed information about incident status changes, please see the Incident Workflow section.
Incidents are anomalous conditions that result in—or may lead to—service degradation or outages. These events require human intervention to avert disruptions or restore service to operational status. Incidents are always given immediate attention.
The goal of incident management is to organize chaos into swift incident resolution. To that end, incident management provides:
When an incident starts, the automation sends a message
containing a link to a per-incident Slack channels for chat based communication, the
incident issue for permanent records, and the Situation Room Zoom link (also in all
incident channel descriptions) for incident team members to join for synchronous verbal
and screen-sharing communication.
There is only ever one owner of an incident—and only the owner of the incident can declare an incident resolved. At anytime the incident owner can engage the next role in the hierarchy for support. With the exception of when GitLab.com is not functioning correctly, the incident issue should be assigned to the current owner.
It's important to clearly delineate responsibilities during an incident. Quick resolution requires focus and a clear hierarchy for delegation of tasks. Preventing overlaps and ensuring a proper order of operations is vital to mitigation.
||The EOC is the usually the first person alerted - expectations for the role are in the Handbook for oncall. The checklist for the EOC is in our runbooks. If another party has declared an incident, once the EOC is engaged the EOC owns the incident. The EOC can escalate a page in PagerDuty to engage the IMOC and CMOC.||The Reliability Team Engineer On Call is generally an SRE and can declare an incident. They are part of the "SRE 8 Hour" on call shift in PagerDuty.|
||The IMOC is engaged when incident resolution requires coordination from multiple parties. The IMOC is the tactical leader of the incident response team—not a person performing technical work. The IMOC assembles the incident team by engaging individuals with the skills and information required to resolve the incident.||The IMOC rotation is currently in the "SRE Managers" Pager Duty Schedule.|
||The CMOC disseminates information internally to stakeholders and externally to customers across multiple media (e.g. GitLab issues, Twitter, status.gitlab.com, etc.).||The Communications Manager is generally member of the support team at GitLab. Notifications to the
These definitions imply several on-call rotations for the different roles.
Current Statussection of the incident issue description. These updates should summarize the current customer impact of the incident and actions we are taking to mitigate the incident.
Timelinesection of the incident issue description, but can be captured in a comment thread, if rapid capture of events is needed. If capturing these events in comments on the incident issue, utilize the same format as the
Timelinesection of the incident issue.
#alerts-generalare an important source of information about the health of the environment and should be monitored during working hours.
productiontracker. See production queue usage for more details.
The Situation Room Permanent Zoom. The Zoom link is in the
The Situation Room Permanent Zoomas soon as possible.
#production. If the alert is flappy, create an issue and post a link in the thread. This issue might end up being a part of RCA or end up requiring a change in the alert rule.
~review-requestedlabel, the EOC should start on performing an incident review, in some cases this may be be a synchronous review meeting or an async review depending on what is requested by those involved with the incident.
At times, we have a security incident where we may need to take actions to block a certain URL path or part of the application. This list is meant to help the Security Engineer On-Call and EOC decide when to engage help and post to status.io.
If any of the following are true, it would be best to engage an Incident Manager:
In some cases, we may choose not to post to status.io, the following are examples where we may skip a post/tweet. In some cases, this helps protect the security of self managed instances until we have released the security update.
Current Statussection of the incident issue regularly updated.
firstname.lastname@example.org via the
GitLab Production - Severity 1 Escalationservice in PagerDuty (app or website) with a link to the incident.
To engage the IMOC: either run
/pd trigger in Slack, then select the "GitLab
Production - IMOC" service, or create an incident in the Pagerduty page for the
For serious incidents that require coordinated communications across multiple channels, the IMOC will rely on the CMOC for the duration of the incident.
The GitLab support team staffs an oncall rotation and via the
Incident Management - CMOC service in PagerDuty. They have a section in the support handbook for getting new CMOC people up to speed.
During an incident, the CMOC will:
If, during an incident, EOC or IMOC decide to engage CMOC, they should do that by paging the on-call person:
/pd triggercommand in Slack, then select the "Incident Management - CMOC" service from the modal. or
Saturday / Sunday 00:00 - 08:00 UTC does not currently have CMOC coverage.
Corrective Actions (CAs) are work items that we create as a result of an incident. Only issues arising out of an incident should receive the label "corrective action". They are designed to prevent or reduce the likelihood and/or impact of an incident recurrence and as such are part of the Incidence Management cycle.
Corrective Actions should be related to the incident issue to help with downstream analysis, and it can be helpful to refer to the incident in the description of the issue.
|Fix the issue that caused the outage||(Specific) Handle invalid postal code in user address form input safely|
|Investigate monitoring for this scenario||(Actionable) Add alerting for all cases where this service returns >1% errors|
|Make sure engineer checks that database schema can be parsed before updating||(Bounded) Add automated presubmit check for schema changes|
Runbooks are available for engineers on call. The project README contains links to checklists for each of the above roles.
In the event of a GitLab.com outage, a mirror of the runbooks repository is available on at https://ops.gitlab.net/gitlab-com/runbooks.
The chatops bot will give you this information if you DM it with
/chatops run oncall prod.
The current EOC can be contacted via the
@sre-oncall handle in Slack, but please only use this handle in the following scenarios.
The EOC will respond as soon as they can to the usage of the
@sre-oncall handle in Slack, but depending on circumstances, may not be immediately available. If it is an emergency and you need an immediate response, please see the Reporting an Incident section.
If you are a GitLab team member and would like to report a possible incident related to GitLab.com and have the EOC paged in to respond, choose one of the reporting methods below. Regardless of the method chose, please stay online until the EOC has had a chance to come online and engage with you regarding the incident. Thanks for your help!
/incident declare in the
#production channel in GitLab's Slack and follow the prompts. This will open an incident issue. If you suspect the issue is an emergency, tick the "Page the engineer on-call" box - not the incident manager or communications manager boxes. You do not need to decide if the problem is an incident, and should err on the side of paging the engineer on-call if you are not sure. We have triage steps below to make sure we respond appropriately. Reporting high severity bugs via this process is the preferred path so that we can make sure we engage the appropriate engineering teams as needed.
Incident Declaration Slack window
|Title||Give the incident as descriptive as title as you can. Please prepend the title with a date in the format YYYY-MM-DD|
|Severity||If unsure about the severity to choose, but you are seeing a large amount of customer impact, please select S1. More details here: Incident Severity.|
|Tasks: page the on-call engineer||If you'd like to page the on-call engineer, please check this box. If in doubt, err on the side of paging if there is significant disruption to the site.|
|Tasks: page on-call managers||You can page the incident and/or communications managers on-call.|
Incident Declaration Results
As well as opening a GitLab incident issue, a dedicated incident Slack channel will be opened. The "woodhouse" bot will post links to all of these resources in the main
#incident-management channel. Please note that unless you're an SRE, you won't be able to post in
#incident-management directly. Please join the dedicated Slack channel, created and linked as a result of the incident declaration, to discuss the incident with the on-call engineer.
Email email@example.com. This will immediately page the Engineer On Call.
This is a first revision of the definition of Service Disruption (Outage), Partial Service Disruption, and Degraded Performance per the terms on Status.io. Data is based on the graphs from the Key Service Metrics Dashboard
Outage and Degraded Performance incidents occur when:
Degradedas any sustained 5 minute time period where a service is below its documented Apdex SLO or above its documented error ratio SLO.
Outage(Status = Disruption) as a 5 minute sustained error rate above the Outage line on the error ratio graph
SLOs are documented in the runbooks/rules
To check if we are Degraded or Disrupted for GitLab.com, we look at these graphs:
A Partial Service Disruption is when only part of the GitLab.com services or infrastructure is experiencing an incident. Examples of partial service disruptions are instances where GitLab.com is operating normally except there are:
In the case of high severity bugs, we prefer that an incident issue is still created via Reporting an Incident. This will give us an incident issue on which to track the events and response.
In the case of a high severity bug that is in an ongoing, or upcoming deployment please follow the steps to Block a Deployment.
If an incident may be security related, engage the Security Engineer on-call by using
/security in Slack. More detail can be found in Engaging the Security Engineer On-Call.
Information is an asset to everyone impacted by an incident. Properly managing the flow of information is critical to minimizing surprise and setting expectations. We aim to keep interested stakeholders apprised of developments in a timely fashion so they can plan appropriately.
This flow is determined by:
Furthermore, avoiding information overload is necessary to keep every stakeholder’s focus.
To that end, we will have:
#incident-managementroom in Slack.
#incident-managementchannel for internal updates
Definitions and rules for transitioning state and status are as follows.
|Investigating||The incident has just been discovered and there is not yet a clear understanding of the impact or cause. If an incident remains in this state for longer than 30 minutes after the EOC has engaged, the incident should be escalated to the IMOC.|
|Identified||The cause of the incident is believed to have been identified and a step to mitigate has been planned and agreed upon.|
|Monitoring||The step has been executed and metrics are being watched to ensure that we're operating at a baseline. If there is a clear understanding of the specific mitigation leading to resolution and high confidence in the fact that the impact will not recur it is preferable to skip this state.|
|Resolved||The incident is closed and status is again Operational.|
Status can be set independent of state. The only time these must align is when an issues is
|Operational||The default status before an incident is opened and after an incident has been resolved. All systems are operating normally.|
|Degraded Performance||Users are impacted intermittently, but the impacts is not observed in metrics, nor reported, to be widespread or systemic.|
|Partial Service Disruption||Users are impacted at a rate that violates our SLO. The IMOC must be engaged and monitoring to resolution is required to last longer than 30 minutes.|
|Service Disruption||This is an outage. The IMOC must be engaged.|
|Security Issue||A security vulnerability has been declared public and the security team has asked to publish it.|
Incident severities encapsulate the impact of an incident and scope the resources allocated to handle it. Detailed definitions are provided for each severity, and these definitions are reevaluated as new circumstances become known. Incident management uses our standardized severity definitions, which can be found under availability severities.
In order to effectively track specific metrics and have a single pane of glass for incidents and their reviews, specific labels are used. The below workflow diagram describes the path an incident takes from
S1 incidents require a review, other incidents can also be reviewed as described here.
GitLab uses the Incident Management feature of the GitLab application. Incidents are reported and closed when they are resolved. A resolved incident means the degradation has ended and will not likely re-occur.
If there is additional follow-up work that requires more time after an incident is resolved and closed (like a detailed root cause analysis or a corrective action) a new issue may need to be created and linked to the incident issue. It is important to add as much information as possible as soon as an incident is resolved while the information is fresh, this includes a high level summary and a timeline where applicable.
The EOC and the IMOC, at the time of the incident, are the default assignees for an incident issue. They are the assignees for the entire workflow of the incident issue.
The following labels are used to track the incident lifecycle from active incident to completed incident review. Label Source
In order to help with attribution, we also label each incident with a scoped label for the Infrastructure Service (Service::) and Group (group::) scoped labels.
||Indicates that the incident labeled is active and ongoing. Initial severity is assigned when it is opened.|
||Indicates that the incident has been mitigated, but immediate post-incident activity may be ongoing (monitoring, messaging, etc.). A mitigated issue means there is the potential for the impact to return. It may be appropriate to leave an incident mitigated while there is an alert silence with an expiration set.|
||Indicates that SRE engagement with the incident has ended and the condition that triggered the alert has been resolved. Incident severity is re-assessed and determined if the initial severity is still correct and if it is not, it is changed to the correct severity. Once an incident is resolved, it should be closed.|
||Indicates that an incident review has been completed, this should be added to an incident after the review is completed if it has the
Labeling incidents with similar causes helps develop insight into overall trends and when combined with Service attribution, improved understanding of Service behavior. Indicating a single root cause is desirable and in cases where there appear to be multiple root causes, indicate the root cause which precipitated the incident.
The EOC, as DRI of the incident, is responsible for determining root cause.
The current Root Cause labels are listed below. In order to support trend awareness these labels are meant to be high-level, not too numerous, and as consistent as possible over time.
||feature or other code change|
||a feature flag toggled in some way (off or on or a new percentage or target was chosen for the feature flag)|
||configuration change, other than a feature flag being toggled|
||the failure of a service or component which is an architectural SPoF (Single Point of Failure)|
||deliberate malicious activity targeted at GitLab or customers of GitLab (e.g. DDoS)|
||failure resulting from a service or component which failed to scale in response to increasing demand (whether or not it was expected)|
||resulting from the failure of a dependency external to GitLab, including various service providers. Use of other causes (such as
||forward- or backwards-compatibility issues between subsequent releases of the software running concurrently, and sharing state, in a single environment (e.g. Canary and Main stage releases). They can be caused by incompatible database DDL changes, canary browser clients accessing non-canary APIs, or by incompatibilities between Redis values read by different versions of the application.|
||an incident where the SIRT team was engaged, generally via a request originating from the SIRT team or in a situation where Reliability has paged SIRT to assist in the mitigation of an incident not caused by
||an incident, usually a deployment pipeline failure found to have been caused by a flaky QA test|
||when an incident has been investigated, but the root cause continues to be unknown and an agreement has been formed to not pursue any further investigation.|
The following labels are added and removed by triage-ops automation depending on whether the corresponding label has been been added.
||Will be added/removed automatically based on there being a
||Will be added/removed automatically based on there being a
||Will be added/removed automatically based on there being at least one link on the
These labels are always required on incident issues.
||Label used for metrics tracking and immediate identification of incident issues.|
||Scoped label for service attribution. Used in metrics and error budgeting.|
||Scoped label for severity assignment. Details on severity selection can be found in the availability severities section.|
||Scoped label indicating root cause of the incident.|
In certain cases, additional labels will be added as a mechanism to add metadata to an incident issue for the purposes of metrics and tracking.
||Indicates that an incident is exclusively an incident for self-managed GitLab. Example self-managed incident issue|
||The incident occurred due to activity from security scanners, crawlers, or other automated traffic|
||Indicates that the incident is a failing deployment or that the incident was caused by a deployment. Failures may be caused by failing tests, application bugs, or pipeline problems. Incidents during deploys may be the result of disconnects or other deploy-related errors.|
||Any development group(s) related to this incident|
||Indicates that that the incident would benefit from undergoing additional review. All S1 incidents are required to have a review. Additionally, anyone including the EOC can request an incident review on any severity issue. Although the review will help to derive corrective actions, it is expected that corrective actions are filled whether or not a review is requested. If an incident does not have any corrective actions, this is probably a good reason to request a review for additional discussion.|
Incident::Resolvedthe incident issue will be closed
Severity::1incidents will automatically be labeled with
The board which tracks all GitLab.com incidents from active to reviewed is located here.
A near miss, "near hit", or "close call" is an unplanned event that has the potential to cause, but does not actually result in an incident.
In the United States, the Aviation Safety Reporting System has been collecting reports of close calls since 1976. Due to near miss observations and other technological improvements, the rate of fatal accidents has dropped about 65 percent. source
Near misses are like a vaccine. They help the company better defend against more serious errors in the future, without harming anyone or anything in the process.
When a near miss occurs, we should treat it in a similar manner to a normal incident.