Is GitLab Down?

No — GitLab is up

Reachable from all 8 checked regions

Average response time: 319ms

Last checked 3 hours ago · checks run every 6 hours

Official status page: https://status.gitlab.com

GitLab uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

324ms

Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 21 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

21-day clean streak

Jul 19 Today

No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

jnb

609ms

DNS 191ms TCP 1ms TLS 9ms TTFB 603ms

lax

315ms

DNS 38ms TCP 1ms TLS 25ms TTFB 305ms

lhr

246ms

DNS 24ms TCP 1ms TLS 7ms TTFB 239ms

nrt

328ms

DNS 29ms TCP 1ms TLS 8ms TTFB 321ms

ord

220ms

DNS 60ms TCP 1ms TLS 8ms TTFB 212ms

sin

519ms

DNS 128ms TCP 1ms TLS 11ms TTFB 510ms

sjc

255ms

DNS 30ms TCP 1ms TLS 10ms TTFB 249ms

syd

486ms

DNS 170ms TCP 1ms TLS 7ms TTFB 480ms

yyz

183ms

DNS 12ms TCP 1ms TLS 6ms TTFB 176ms

What GitLab does

GitLab is a DevOps platform combining Git repository hosting, issue tracking and CI/CD pipelines in a single application. Teams use gitlab.com as the origin for their source code and as the runner of their build and deploy jobs, which makes it a dependency for shipping software rather than only for storing it.

What an outage looks like

Git push and pull over HTTPS or SSH hang or fail outright, and the web interface returns 500 or 502 pages. Pipelines queue without ever picking up a runner, or jobs fail the moment they try to pull from the container registry. Merge requests may load while comments and pipeline results appear minutes late.

What to do about it

Check status.gitlab.com, which reports Git Operations, CI/CD, hosted runners and the package and container registries as separate components, so a stalled pipeline does not always mean pushes are affected. Queued jobs generally run once runners recover rather than needing to be retriggered. Keep committing locally: Git holds your history until the origin returns.

Is it down for everyone, or just you?

If this page says GitLab is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

GitLab outage FAQ

Is GitLab down or is it just my pipeline?

status.gitlab.com breaks CI/CD out from Git Operations and lists hosted runners for Linux, Windows and macOS individually. A job that never starts while pushes and the web interface work normally points at a runner component rather than at GitLab as a whole. If every component is green, look at your own .gitlab-ci.yml or runner configuration.

Will my queued CI/CD jobs run after the outage?

Generally yes. Jobs sitting in the queue are picked up once runners come back, so retriggering the whole pipeline is usually unnecessary and can double the work waiting to be processed. Watch the queue for a few minutes after the status page clears before deciding anything is genuinely stuck and needs a manual retry.

Can I keep working while GitLab.com is down?

Yes, for anything local. Git is distributed, so commits, branches, history and diffs all work against your local clone with no server involved. What you cannot do is push, open or review merge requests, or run pipelines. Commit as normal and push the accumulated work once Git Operations is reported healthy again.

Does a GitLab.com outage affect self-managed GitLab instances?

No. Self-managed instances run on your own infrastructure and are independent of gitlab.com. The exceptions are features that reach out to GitLab-operated services, such as licence checks, the public package registry, or shared runners if you use them. status.gitlab.com covers the SaaS platform, not your own installation.

Why did my deployment fail when GitLab looked up?

Deployments touch several components at once. A job can start normally and then fail pulling an image from the Container Registry or a dependency from the Package Registry, both of which are reported separately from CI/CD. Read the job log for where it broke rather than the overall status pill, then match that step to its component.

How we measure this

We request GitLab's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
Response times average only the regions that actually served the page, so a timeout never inflates the number.
Where GitLab publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when GitLab goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring

Free plan available No credit card required