Availability Measurement for GitLab SaaS Services
This policy specifies how availability is measured for GitLab.com, GitLab Dedicated and GitLab Dedicated for Government
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to
controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
GitLab Service Level Agreement - Availability Definition
The following service level agreement applies to SaaS Software purchased or renewed as Ultimate tier on or after 2026-01-01.
Service Availability Commitment
GitLab commits 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”):
-
Issues and Merge Requests
-
Git Operations (push, pull, clone via HTTPS and SSH)
-
Container Registry operations
-
Package Registry operations
-
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:
Properly authenticated and authorized - The request includes valid authentication
credentials and the user has appropriate permissions for the requested operation
Correctly formed - The request:
Uses documented API endpoints, parameters, and methods
-
Follows GitLab’s published API specifications and documentation
-
Contains syntactically correct Git commands (for Git operations)
-
Includes required headers and properly formatted request bodies
Within usage limits - The request:
Does not exceed documented rate limits
-
Does not exceed size limits (e.g., file size, repository size, payload size)
-
Originates from non-blocked IP addresses or users
-
Complies with fair use policies
Non-malicious - The request:
Does not attempt to exploit security vulnerabilities
-
Does not contain malicious code or payloads
-
Is not part of a DDoS or other attack pattern
-
Does not attempt to circumvent access controls
Supported operations - The request:
Targets features included in the customer’s subscription tier
- Uses generally available features (not experimental/beta)
The following are excluded from Valid Requests:
-
Requests that receive HTTP 4xx errors due to client-side issues
-
Requests to deprecated API endpoints after the deprecation date
-
Requests from automated testing or monitoring tools not operated by GitLab
-
Preflight/OPTIONS requests
-
Health check or status endpoint requests
Excluded Minutes
The following minutes are excluded from being counted as Downtime Minutes:
-
Scheduled Maintenance windows
-
Emergency maintenance necessary to address critical security or data integrity issues
-
Force Majeure events or general Internet connectivity issues
-
Issues caused by Customer’s use of the Service in violation of the Terms of Service
-
Issues caused by equipment, software, or services not provided or controlled by GitLab