Skip to main content
GitLab logo

Is GitLab Down?

No — GitLab is up

Reachable from all 8 checked regions

Average response time: 300ms

Last checked · 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
370ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 1 day measured so far. A dash means we have no measurement for that window.

30-day history

Jun 30: no data
Jul 1: no data
Jul 2: no data
Jul 3: no data
Jul 4: no data
Jul 5: no data
Jul 6: no data
Jul 7: no data
Jul 8: no data
Jul 9: no data
Jul 10: no data
Jul 11: no data
Jul 12: no data
Jul 13: no data
Jul 14: no data
Jul 15: no data
Jul 16: no data
Jul 17: no data
Jul 18: no data
Jul 19: no data
Jul 20: no data
Jul 21: no data
Jul 22: no data
Jul 23: no data
Jul 24: no data
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: 100.00% uptime, 16 checks
Jul 29: no data
Jun 30 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.

bom
847ms
DNS 49ms TCP 15ms TLS 14ms TTFB 649ms
cdg
366ms
DNS 113ms TCP 5ms TLS 12ms TTFB 352ms
dfw
276ms
DNS 111ms TCP 2ms TLS 10ms TTFB 265ms
ewr
216ms
DNS 51ms TCP 1ms TLS 11ms TTFB 208ms
fra
308ms
DNS 23ms TCP 1ms TLS 12ms TTFB 295ms
gru
367ms
DNS 129ms TCP 2ms TLS 6ms TTFB 359ms
iad
156ms
DNS 13ms TCP 0ms TLS 9ms TTFB 148ms
jnb
376ms
DNS 16ms TCP 0ms TLS 7ms TTFB 372ms
lax
340ms
DNS 65ms TCP 1ms TLS 16ms TTFB 314ms

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, and let it override us in both directions.

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