Is GitLab Down?

No — GitLab is up

Reachable from all 8 checked regions

Average response time: 397ms

Last checked 5 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

363ms

Avg response, 30 days

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

30-day history

55-day clean streak

Aug 22 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.

arn

589ms

DNS 155ms TCP 1ms TLS 7ms TTFB 581ms

bom

649ms

DNS 205ms TCP 3ms TLS 10ms TTFB 635ms

cdg

311ms

DNS 49ms TCP 1ms TLS 11ms TTFB 302ms

dfw

256ms

DNS 50ms TCP 1ms TLS 9ms TTFB 249ms

ewr

188ms

DNS 35ms TCP 2ms TLS 7ms TTFB 179ms

fra

350ms

DNS 42ms TCP 1ms TLS 9ms TTFB 341ms

gru

541ms

DNS 127ms TCP 2ms TLS 8ms TTFB 530ms

iad

299ms

DNS 125ms TCP 1ms TLS 7ms TTFB 291ms

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 up to 18 cities across three 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 — the most recent check ran from 8 of them.
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 up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring

Free plan available No credit card required