Is GitLab down right now?
Live status for gitlab.com isn't set up in this environment yet - check any URL manually instead.
Checking gitlab.com right now
A fresh check, started when you opened this page - each probe runs its own independent DNS, TCP, TLS and HTTP request. Anonymous runs sample the network; a signed-in account checks from more locations.
About GitLab outages
Written by the HostTracker monitoring team · updated from live probe data.
GitLab combines source control, CI/CD pipelines, and a container registry into one platform, and gitlab.com serves as the shared home for an enormous number of independent projects at once. Because of that, a real gitlab.com incident tends to be broad and visible across unrelated teams simultaneously - but the platform is also componentized enough that a single piece, most often the shared CI runner pool, can back up under demand without git operations or the web interface being affected at all. It's worth remembering, too, that self-managed GitLab instances run on infrastructure entirely separate from gitlab.com, so a self-hosted install is never affected by an incident on the shared cloud service.
Common causes of GitLab downtime
Shared CI runner capacity queueing under heavy demand, which delays pipeline jobs long enough to look like an outage even though nothing has actually failed
Git operations over SSH and over HTTPS relying on different infrastructure paths, so one can fail while the other keeps working for the same repository
Container registry incidents that block image pushes and pulls independently of whether the rest of GitLab is reachable
Scheduled database maintenance windows that briefly degrade specific features while the core site stays up
Self-managed GitLab instances running on entirely separate infrastructure from gitlab.com, so they are never affected by a gitlab.com incident regardless of what this page shows
Not sure whether it's GitLab or your own connection? Read the full breakdown in our website down checker guide for a general walkthrough of diagnosing any outage, from DNS failures to expired certificates.
Other services we track
HostTracker has monitored websites and online services since 2004 and is trusted by 500,000+ sites today, covering 14 check types from 300+ global locations. Want the same multi-location confirmation and instant alerts for your own site or any service you depend on? Getting started costs nothing - start a free monitor or compare plans and pricing.
Questions people ask during an outage
The live probe run on this page tests gitlab.com from a broad sample of HostTracker's 300+-location monitoring network - many independent networks at the same moment, rather than just your own connection. If every location fails to reach it, the outage is real and affects everyone; if only a few locations fail while most load normally, the problem is local to those regions or networks rather than GitLab being fully down. A single refresh from your own browser can never make that distinction, because it only ever tests from one vantage point on one network.
Yes. HostTracker lets you add any URL - including third-party services you depend on, not just your own website - as a monitored target, and notifies you automatically the moment it becomes unreachable. Before sending an alert, HostTracker re-verifies a failure from multiple locations in its 300+-location network, so you're notified about real, confirmed outages rather than a single location's momentary blip. The free plan checks two monitors every 30 minutes indefinitely at no cost; paid plans check as often as once a minute, with alerts available through SMS, email, voice call, and several messenger apps.
Run the live check at the top of this page - it tests gitlab.com from HostTracker's 300+ monitoring locations at once and tells you within seconds whether GitLab is reachable for everyone or only failing for you.
Not necessarily a platform outage. GitLab's shared CI runners serve a huge number of projects from a common pool, and heavy demand at busy times can queue jobs for an extended stretch without anything having actually failed - the job is waiting for a runner to become free, not stuck on a broken system. If git push/pull and the web interface both work normally while only pipeline jobs are slow to start, that points at runner capacity rather than a wider incident.
Git operations over SSH, Git over HTTPS, and the web UI are served by different parts of GitLab's infrastructure, so it's entirely possible for one to keep working while another is degraded. This split is useful for narrowing down an incident: if SSH pushes succeed but the website times out, the problem is more likely in the web-facing layer than in core Git storage, and checking each path separately gives a clearer picture than assuming the whole platform is affected.
No. A self-managed GitLab installation runs entirely on its own infrastructure, whether that's on-premises or in a private cloud account, and shares none of it with gitlab.com. An incident on the shared cloud service, however widespread, has no technical path to affect a self-hosted instance - the two are only related by sharing the same software, not the same servers.
Monitor your website from 300+ locations
Start a free trial and get instant alerts when your site goes down - verified from multiple locations before you're notified.