Service Level Availability is the percentage of time that GitLab Dedicated ("Dedicated") is in an available state for use by a customer over a given calendar month. This document defines how Service Level Availability is calculated for Dedicated.
GitLab calculates Service Level Availability based on the available state of certain services and features provided with Dedicated. The services and features that are considered when calculating Service Level Availability include:
| Service | Features |
|---|---|
| webservice | GitLab Issues, Merge Requests, CI Job Logs Page; GitLab API; Git Push, Pull, Clone Operations over HTTPS |
| registry | Container Registry HTTPS requests |
| gitlab-shell | Git Push, Git Pull, Clone Operations over SSH |
For each service and feature described above, GitLab measures two service level indicators ("SLIs"), as further described in https://gitlab.com/gitlab-com/runbooks/-/tree/master/reference-architectures/get-hybrid#service-level-indicators:
Combining these two SLIs, GitLab scores each request as follows:
| Server Error? | Latency <= 1s | Latency <= 10s | Latency > 10s |
|---|---|---|---|
| No | 1 | 0.5 | 0 |
| Yes | 0 | 0 | 0 |
Service Level Availability is then calculated using the following measurement:
For each calendar month, we calculate the sum of the combined SLI scores for all requests in that month, excluding any requests made during maintenance windows, and divide this by the total number of requests during that period (again, excluding maintenance windows).
Service Level Availability = the sum of qualifying SLIs for the entire month divided by the total qualifying requests for the entire month. The Service Level Availability of GitLab Dedicated should meet or exceed the current Service Level Objective (defined below).
GitLab's current monthly service level objective for GitLab Dedicated is 99.5% (the "Service Level Objective").
Calculation of Service Level Availability does not include failures resulting from (1) misuses or misconfiguration of the applicable service or feature provided with Dedicated, (2) customer activity outside GitLab's terms of service, (3) components or services not defined in the Scope section (above), (4) factors outside of GitLab’s reasonable control, such as force majeure events, or (5) Customer’s or selected cloud hosting providers services, equipment or other technologies. Scheduled maintenance or urgent unscheduled system maintenance necessary to address critical issues (e.g. security vulnerabilities, data consistency issues, etc) are also not included in the calculation of Service Level Availability.
GitLab has developed a disaster recovery plan (the "Plan") to minimize the impact of a disaster or other emergency impacting a customer's access to and use of Dedicated
The Plan is scoped to disasters or other emergency events impacting the following:
The recovery time objective ("Recovery Time Objective" or "RTO") for the Plan is based on how long it takes to re-provision the required infrastructure and restore data from the most recently available backup.
The recovery point objective ("Recovery Point Objective" or "RPO") for the Plan is based on the frequency of snapshots across the data sources.
In order to receive RPO and RTO targets, customers must specify a primary and secondary region upon onboarding. For customers who have only specified a primary region, GitLab will still make a good faith effort to recover pursuant to the Plan, but the RTO and RPO goals of the Plan will not be considered.
GitLab regularly tests the Plan and will take all commercially reasonable efforts to ensure its success within the below RTO/RPO goals.
Events that have a more severe impact in a customer's access to and use of Dedicated, such as loss to both primary and secondary regions, global internet outages, or data corruption issues, are out of scope from the Plan. GitLab will still make a good faith effort to recover pursuant to the Plan, but the RTO and RPO goals of the Plan will not be considered.
8 hours
4 hours
