# GitLab status

> Is GitLab.com down? Live status, uptime history, and per-region response times measured by our own probes every 2 minutes from five locations.

Published: 2026-08-23 | Canonical: https://yoping.me/status/gitlab

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/gitlab. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.