If your security and vulnerability reports failed to load or ingest on GitLab on 29 September 2026, that was GitLab's own backlog problem, not yours. The incident ran 18 hours and 10 minutes, from 18:20 UTC to around midday the next day, UTC.
Started
18:20 UTC
Duration
Lasted 18h 10m
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.
What happened?
GitLab opened this incident at 18:15 UTC, saying security and vulnerability reports were not loading or being ingested for some users, and that it was investigating. By 18:36 it had identified a cause and was working on a mitigation, though it never named what the cause was in any update shown here. At 19:06 it reported the mitigation was reducing a backlog of events and said it was now monitoring. Updates at 20:01 and 21:12 both describe continued improvement across GitLab's graphs and a shrinking backlog, but without numbers, so you cannot tell from these posts how close to normal things actually were. At 22:29 and again at 00:02 the language shifts to a holding pattern: a backlog of ingestion events was still being processed, and GitLab said it expected that to take some time. By 07:19 UTC the next day GitLab posted that there were no material updates, repeating that it was continuing to monitor the backlog and working on mitigation. A second no material updates post came at 09:17. The incident record shows no formal resolution update and the duration given is 18 hours 10 minutes. No components list was published alongside this incident, and GitLab's status page does not say why the ingestion pipeline backed up in the first place. No user reports were filed during the window on this page, so the user-facing impact here is defined entirely by GitLab's own wording of "some users".
Learning
This incident affected GitLab's security and vulnerability report ingestion pipeline, a backend processing layer that sits behind the interface you actually use. A check that only pings whether gitlab.com responds would stay green through something like this, because the front door was open even while a backlog built up behind it. That is the general shape of this kind of failure: the page loads, the login works, but a specific feature depending on asynchronous processing quietly stops delivering fresh data for many hours. GitLab's own updates confirm this, since they talk about graphs improving and backlogs shrinking rather than any user-facing error state. Watching only your own endpoints would not have caught this, because your product could have called GitLab's API successfully the whole time and still received stale or missing report data. Over the last 90 days GitLab has logged 30 incidents with a median duration of 3 hours 49 minutes, so an 18-hour backlog is well outside its typical pattern. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
