Availability Measurement for GitLab SaaS Services

GitLab Service Level Agreement - Availability Definition

Service Availability Commitment

GitLab will use commercially reasonable efforts to make the Covered Experiences available with a Monthly Uptime Percentage of at least 99.9% during each calendar month.

Covered Experiences

The following GitLab features and services are covered under this SLA (“Covered Experiences”):

1. Issues and Merge Requests
2. Git Operations (push, pull, clone via HTTPS and SSH)
3. Container Registry operations
4. Package Registry operations
5. API Requests (limited to the above Covered Experiences only)

Downtime Minute Definition

A “Downtime Minute” occurs when:

The Service experiences degraded availability, meaning 5% or more of Valid Customer Requests to Covered Experiences in a given minute result in server errors (defined as HTTP 5xx status codes or connection timeouts exceeding 30 seconds) as determined by GitLab’s internal and external monitoring systems.

Downtime Minutes do not include any Excluded Minutes as defined in this document.

Valid Request Definition

“Valid Request” means a request that meets all of the following criteria:

1. Properly authenticated and authorized - The request includes valid authentication credentials and the user has appropriate permissions for the requested operation

2. Correctly formed - The request:

   1. Uses documented API endpoints, parameters, and methods
   2. Follows GitLab’s published API specifications and documentation
   3. Contains syntactically correct Git commands (for Git operations)
   4. Includes required headers and properly formatted request bodies

3. Within usage limits - The request:

   1. Does not exceed documented rate limits
   2. Does not exceed size limits (e.g., file size, repository size, payload size)
   3. Originates from non-blocked IP addresses or users
   4. Complies with fair use policies

4. Non-malicious - The request:

   1. Does not attempt to exploit security vulnerabilities
   2. Does not contain malicious code or payloads
   3. Is not part of a DDoS or other attack pattern
   4. Does not attempt to circumvent access controls

5. Supported operations - The request:

   1. Targets features included in the customer’s subscription tier
   2. Uses generally available features (not experimental/beta)

The following are excluded from Valid Requests:

1. Requests that receive HTTP 4xx errors due to client-side issues
2. Requests to deprecated API endpoints after the deprecation date
3. Requests from automated testing or monitoring tools not operated by GitLab
4. Preflight/OPTIONS requests
5. Health check or status endpoint requests

Excluded Minutes

The following minutes are excluded from being counted as Downtime Minutes:

1. Scheduled Maintenance windows
2. Emergency maintenance necessary to address critical security or data integrity issues
3. Force Majeure events or general Internet connectivity issues
4. Issues caused by Customer’s use of the Service in violation of the Terms of Service
5. Issues caused by equipment, software, or services not provided or controlled by GitLab
6. Features or services explicitly labeled as Alpha, Beta, or Preview

Calculating Monthly Uptime Percentage

“Monthly Uptime Percentage” is calculated as:

$$\text{Monthly Uptime Percentage} = \frac{\text{Total Minutes in Month} - \text{Downtime Minutes}}{\text{Total Minutes in Month}} \times 100$$

Where:

• “Total Minutes in Month” = Total number of minutes in the calendar month
• “Downtime Minutes” = Total number of minutes in a calendar month when Covered Experiences met the Downtime Minute definition, excluding any Excluded Minutes

Credit eligibility

Raise a request through support.GitLab.com to check if you are eligible for credits caused by downtime.

View page source - Edit this page - please contribute.