This workflow outlines the support team's role in GitLab.com Incident Management as well as guidelines for initiating an incident.
From our engineering handbook, incidents are anomalous conditions that result in service degradation or outages and require human or automated intervention to restore service to full operational status in the shortest amount of time possible.
If you're observing issues on GitLab.com or working with users who are reporting issues, please follow the instructions found on the On-Call page and alert the Engineer On Call (EOC).
Generally, issues rated ~S1 or ~S2 should be immediately considered for incident management. However, it's in the best interest of our users and the reliability of GitLab.com that you err on the side of caution and ask if unsure.
|Label||Meaning||Functionality||Affected Users||GitLab.com Availability||Performance Degradation|
|~S1||Blocker||Unusable feature with no workaround, user is blocked||Impacts 50% or more of users||Outage, Significant impact on all of GitLab.com|
|~S2||Critical Severity||Broken Feature, workaround too complex & unacceptable||Impacts between 25%-50% of users||Significant impact on large portions of GitLab.com||Degradation is guaranteed to occur in the near future|