GitLab.com had two separate outages on 24 September 2026, one lasting 7 hours and another 3 hours 3 minutes. Both were GitLab's own infrastructure problems, affecting projects, pipelines and the API, not anything in your repository or CI configuration.
Started
13:52 UTC
Duration
Lasted 7h 0m
Source
IsDown
Next time
GitLab is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Website, API, Git Operations, Container Registry, GitLab Pages, CI/CD - GitLab SaaS Shared Runners, CI/CD - GitLab SaaS Private Runners, CI/CD - Windows Shared Runners (Beta), SAML SSO - GitLab SaaS, Background Processing, GitLab Customers Portal, Support Services, packages.gitlab.com, version.gitlab.com, forum.gitlab.com, Canary
What happened?
The first incident started at 13:52 UTC, when GitLab began receiving reports that users could not access projects and were getting 500 error messages. A user in Serbia reported at 14:06 UTC that they could not run a pipeline, getting the message "Pipeline cannot be run." GitLab applied a temporary mitigation by 14:10 but said the root cause was still under investigation. Updates over the next several hours describe intermittent improvement, then no material change, then a renewed investigation, before GitLab finally said at 18:32 that it had identified the potential cause and was working on a fix. The incident ran for 7 hours before resolution, touching Website, Git Operations, API and other components on GitLab's own status page. A second, separate incident began at 23:04 UTC, with 503 errors across GitLab.com. A user in Poland reported at 23:02 UTC that "gitlab returns 503 on website and terminal commands does not work as well." GitLab identified a cause within 25 minutes and confirmed the API was also affected, then spent the next two and a half hours mitigating as error rates gradually dropped. That second incident lasted 3 hours 3 minutes. Across the day, 16 components were listed on GitLab's status page as potentially affected, though the actual impact at any one time was narrower and shifted between the two incidents. No post-mortem for either incident has been published, and neither update set names a definitive root cause beyond "identified the potential cause" and "identified the cause" without further detail.
Learning
This pair of outages shows a pattern typical of GitLab.com: errors surfaced in the application layer, on GitLab's servers and databases, somewhere you cannot reach from outside. An external check pinging GitLab.com's homepage can come back green while you are still getting 500s on a specific project page or 503s mid pipeline run, because the failure is partial and intermittent rather than a full outage of the whole domain. That is exactly what GitLab's own updates describe, with "intermittent improvements" and error rates that decreased but did not reach zero for hours. Over the last 90 days GitLab has logged 30 incidents with a median duration of 3 hours 49 minutes, so a multi-hour outage like this one is not unusual for this provider. If your own monitoring only watches your product's endpoints, it will stay silent through this kind of failure because your code never changed, GitLab's did. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
