GitLab's security report generation broke for some users for 4 hours and 19 minutes on 25 September 2026. GitLab says the cause was identified quickly but the fix itself stalled for most of the window.
Started
18:43 UTC
Duration
Lasted 4h 19m
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 logged one incident this day, starting at 18:43 UTC and running 4 hours 19 minutes: some users could not generate security reports in pipelines. GitLab's first update, at 18:39, said the cause had been identified and mitigation was underway. That turned out to be optimistic. Over the next three and a half hours GitLab posted seven more updates, and most of them say the same thing in different words: the team is still working on the fix. At 20:45 GitLab reported that "the changes we've tried have so far been ineffective. The fix is still in progress." That line is the clearest signal on the page: whatever they deployed as a first attempt did not work, and they tried again. By 22:26 the last update still described the team as working on mitigating the underlying cause, with no confirmation of resolution in the record shown. GitLab did not publish a component list for this incident and no affected components are named beyond the pipeline security reports feature itself. No user reports were filed during the window on this record. GitLab has not published a post-mortem explaining why the initial fix failed, so that detail is not on the record. Across the last 90 days GitLab has logged 30 incidents with a median duration of 3 hours 49 minutes, so this one ran a bit longer than typical but not wildly out of line with GitLab's recent pattern.
Learning
This incident sat inside GitLab's pipeline processing layer, specifically the step that generates security reports, which is not something an external uptime check against gitlab.com's front door would ever touch. A probe hitting the main site or API would have kept returning green the whole time, because the homepage and login were never the problem. That is exactly the kind of fault that slips past availability monitoring aimed at your own endpoints: your product calling GitLab's API might see failed report generation while every basic health check on both sides stays clean. GitLab's own repeated "still working on the fix" updates, including one admission that an earlier fix attempt failed, show this was a real internal struggle, not a labelling exercise. If your pipelines depend on GitLab's security scanning, the only way to know this was happening in real time was watching GitLab's own status feed or noticing failed reports directly, since your side of the integration had nothing wrong to report. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
