GitLab logged two separate incidents on 1 October 2026: an 11h 37m delay in email delivery starting at 00:38 UTC, and a 3h 20m delay affecting CI/CD jobs on shared runners starting at 18:31 UTC. Both were GitLab's own infrastructure and provider relationships, not anything in your code or pipeline configuration.
Started
00:38 UTC
Duration
Lasted 11h 37m
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: CI/CD - GitLab SaaS Shared Runners, Background Processing
What happened?
The first incident began at 00:38 UTC, when GitLab detected email delivery delays affecting a small number of email service providers. GitLab escalated directly with its email delivery provider and, over the next few hours, posted updates at 00:51, 02:06 and 03:42 describing continued escalation and measures to reduce elevated email volumes. By 06:51 GitLab reported no bounced emails observed since 02:29 UTC, though some messages could still be delayed or fail for certain providers. A final update at 08:49 confirmed no new bounces since 02:29 UTC and said monitoring would continue. The incident's total duration is recorded as 11h 37m, even though the active bounce problem appears to have stopped sending by around 02:29 UTC according to GitLab's own updates. The second incident started at 18:31 UTC, when some CI/CD jobs on saas-linux-small-amd64 hosted runners began experiencing delays before starting. GitLab said it was restoring runner capacity and monitoring recovery, and by 18:47 reported that jobs were processing normally again and graphs had returned to normal. Updates at 19:53 and 21:12 confirmed job processing remained stable, with the incident formally closed after 3h 20m. GitLab did not state a root cause for the runner delays. No user reports were filed during either window, and no post-mortem has been published for either incident.
Learning
Both incidents here sat on GitLab's side of the fence: a third-party email delivery relationship in one case, and shared CI/CD runner capacity in the other. Neither is something your own endpoint checks would catch, because your product's uptime from an external monitor's point of view has nothing to do with whether GitLab's outbound email queue is backing up or whether its shared runners are short on capacity. That is the general shape of this kind of failure: the thing that breaks is a layer you depend on but cannot see into, and your own monitoring stays green the whole time because your service really is up. GitLab's own status updates are the only record of what happened, and a vendor's status page carries real weight, but it is also the only source, so gaps in explanation, like the missing root cause for the runner delays, stay gaps. Over the past 90 days GitLab logged 31 incidents with a median duration of 3 hours 49 minutes, so a multi-hour disruption on their side is not unusual. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
