GitLab: SLA evidence report

2026-09-05 to 2026-10-05 · measured by RealUptime from independent regions · generated Oct 5, 2026, 9:04 PM UTC

GitLab: SLA evidence report

Measured downtime
1h 23m
Across 1 outage in this window.
Window
2026-09-05 to 2026-10-05
UTC, 30 days.
  • Sep 24, 2026, 10:57 PM UTC to Sep 25, 2026, 12:19 AM UTC

    Multiple regions: Europe, South America, US-East, UK, Asia-Pacific, US-Central, Southeast Asia, US-West, Canada

    1h 23mmeasured in this window

    GitLab's claim at the time: No readable claim from their status page during this outage

What we probed

primary
https://gitlab.com/api/v4/projects/278964
secondary
https://status.gitlab.com/

Estimate an SLA credit

Enter what you pay GitLab for this period and their own stated SLA target. This estimates a credit from the measured downtime above. It is one common way to reason about an SLA credit, not GitLab's own contract terms, and it is not a legal determination. RealUptime is not counsel.

Based on 82.5 measured downtime minutes across this report's window.

Methodology

Every outage above is a period our probes measured GitLab as down from enough of the regions we check it from to count as a real outage, not a single unreliable reading (see how we tell the difference). Measured downtime is the wall-clock time inside the window an outage's regions were failing; regions failing together still count as one outage, not one per region.

GitLab's claim at the time comes from their own public status feed, polled on our own schedule, and is shown separately from what we measured. We never change our own reading based on what a vendor claims, and their claim never becomes our reading.

This is one external observation from RealUptime's own regions, not GitLab's own SLA measurement, which is usually defined against their own instrumentation and may cover a different scope than what we probe. The credit estimate above is a starting point for a conversation with GitLab, not a legal determination, and RealUptime is not counsel.