GitLab backs 99.9% availability with service credits for Ultimate customers

GitLab now backs its 99.9% availability commitment with service credits for Ultimate customers on GitLab.com and GitLab Dedicated. When monthly availability falls below this threshold, eligible customers receive credits toward future invoices. This commitment ensures your DevSecOps workflows have the reliability they need.We value your trustModern software delivery operates at a velocity where teams push code, open merge requests, and track issues continuously throughout the day. Git operations — push, pull, clone — happen thousands of times per hour across distributed teams. When any of these core experiences become unavailable, your entire software delivery workflow stops.The 99.9% availability service-level agreement (SLA) ensures your accelerated development pace doesn't hit infrastructure walls. Service credits demonstrate our accountability — tying our success to platform reliability and aligning our interests with yours. We hold ourselves accountable to your business outcomes, not just availability targets.GitLab's SLA commitment covers the core platform services essential to your DevSecOps workflows.At launch, the covered experiences are:* 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)The most up-to-date list of covered and excluded experiences is available in the GitLab handbook.Service availability is measured using automated monitoring across multiple geographic locations, providing an accurate representation of actual service availability experienced by customers. When availability falls below 99.9%, customers are eligible to claim credits based on the severity of the shortfall.Understanding downtime minutesWhen the GitLab service experiences degraded availability of 5% or more of valid customer requests for covered experiences in a given minute, resulting in server errors, this is called a downtime minute. Server errors are defined as HTTP 5xx status codes or connection timeouts exceeding 30 seconds as determined by GitLab's internal and external monitoring systems.The SLA measures server-side failures, but some issues may not trigger 5xx errors, such as application bugs that make features unusable, Sidekiq job processing outages, or infrastructure problems that degrade performance without failing requests outright.Here’s how you can claim service credits when applicable:Submit a support request at support.gitlab.com within thirty (30) days after the end of the affected month to claim downtime credits.The GitLab team reviews the claim, validates the downtime, and processes the credit if applicable.Service credits will be applied against your next issued invoice.Read the handbook for more on how monthly uptime availability is calculated, the service credits offered when applicable, and the credit claim procedures.While our monitoring is designed to capture the vast majority of service disruptions, if your experience doesn't match reported availability, we encourage you to submit a service credit claim. GitLab will review the claim holistically, including investigating issues that may not be reflected in automated monitoring.Reliability you can count onThe 99.9% availability SLA with service credits represents our commitment to being a reliable foundation for your software delivery workflows. Your teams depend on GitLab to keep shipping, and we're here to back you up.Questions about the SLA? Contact your GitLab account team or submit a request through GitLab Support.

Source: https://about.gitlab.com/blog/gitlab-backs-99-9-availability-with-service-credits-for-ultimate-customers/