GitLab status

How we check GitLab

We watch gitlab.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the hosted service itself, the hostname your browser opens and your git client pushes to, rather than a health path that can keep answering while the product behind it is unusable. This page covers GitLab.com only; a self-managed GitLab you run yourself has entirely separate availability that nothing here measures.

What is GitLab?

GitLab is a development platform that puts source control, code review, CI/CD, package registries, and issue tracking in one application. The hosted version at gitlab.com is what this page watches, and the distinction from self-managed installations matters more here than for most services, because a large share of GitLab's users run their own instance and are entirely unaffected by anything happening to the hosted one.

For teams on gitlab.com, the platform's breadth is what makes an incident expensive. Because the same system holds the repository, the pipeline definitions, the runners, the container registry, and the review process, a degradation does not remove one tool from the workflow, it removes the workflow. Code cannot be reviewed, merged, built, or shipped, and the work that was in flight sits where it stopped. Teams that split those functions across separate tools have more integration work on an ordinary day and more options on a bad one.

CI is the most common source of confusion, and specifically the difference between GitLab being unavailable and there being nowhere to run a job. Pipelines that sit queued are usually not evidence of an outage. Shared runner capacity is finite, self-hosted runners go offline without announcing it, and a job whose tags do not match any available runner will wait indefinitely while the platform is entirely healthy. Checking that a runner is registered, online, and eligible for the job is a faster diagnosis than reading any status page.

The split between the web application and the git transport is the second thing worth knowing. They fail independently, so the site loading tells you nothing reliable about whether pushes are working, and a colleague saying "GitLab is fine for me" may be describing a different subsystem entirely. Trying the other protocol, SSH against HTTPS, narrows it quickly.

Finally, a note on the shape of the dependency. Because GitLab hosts the repository as well as the pipelines, an outage blocks not only shipping but also the ordinary act of getting a copy of the code. Local clones are complete, which is one of git's better properties, so work does not stop in the way it would with a centralised version control system. What stops is everything built around the repository, which for most teams is the part that turns a commit into a release.

Frequently asked questions

Is GitLab.com down right now?

Check the board above; it reflects our own probes against gitlab.com from all five of our regions, refreshed every couple of minutes. A single region seeing a failure does not make this page say down, a second region has to agree first.

Does this page cover my self-managed GitLab?

No. This page watches GitLab.com, the hosted service. A GitLab instance you run on your own infrastructure has its own availability, determined by your servers, network, and upgrades, and nothing measured here says anything about it.

My pipelines are queued but not running. Is GitLab down?

Not necessarily, and runner capacity is the more common explanation. Jobs sit queued when no runner is available to pick them up, which happens when shared runner capacity is saturated, when your own runners are offline, or when a job's tags do not match any available runner. Check whether a runner is actually registered and online for the project before treating it as a platform incident.

Why does the web interface work while git push fails?

Because they are different paths through the platform. The web application and the git transport are separate, and GitLab's own status page tracks them separately for that reason. If the site loads and pushes hang, try the other protocol, since a failure that follows SSH but not HTTPS or the reverse tells you a lot in a few seconds.

How is this different from GitLab's own status page?

Their page reports what GitLab's engineers have confirmed from inside the platform, broken down by component. This page reports what our probes measured from outside it, on a fixed schedule, whether or not an update has been published yet. During an incident the two are worth reading together.