Skip to content

Developer outages: September 2026

This week, some GitLab users could not open their projects or use Git normally. Claude returned intermittent errors across its web app and developer tools, while Cursor dealt with two separate incidents.

GitLab’s report gives us the clearest recovery story: restarting an affected server didn’t help, but rolling back its software did. We’ll look at that sequence first, then at what the Claude and Cursor reports tell us about which features failed together.

In this report

GitLab: repository access recovered after a rollback

17–18 September. GitLab reported HTTP 500 errors when users opened certain projects or used Git. The problem affected repository access through both the website and Git operations. Official incident report.

GitLab focused its recovery work on Gitaly, the service that reads and writes Git repositories. The website and Git operations both depend on it. That shared dependency explains how a repository problem can surface in two places that look separate to a user. GitLab’s Gitaly documentation describes the connection.

The incident continued overnight. At 02:34 UTC on September 18, GitLab reported that restarting an affected Gitaly server had not improved the errors. It subsequently rolled back the Gitaly deployment. By 09:01 UTC, it reported that the rollback had reached all Gitaly servers and they were stable. The closing update at 13:45 UTC confirmed restored repository access.

A restart leaves the installed software version in place. A rollback returns to an earlier version. Here, the first action did not restore access; the second did. For developers responsible for releases, that is a reason to keep a previous version deployable. A rollback also needs to account for database changes: earlier code must still be able to read the data it will encounter.

The successful rollback does not establish the exact fault. An early update attributed the incident to an abuse vector, but the closing update said the root cause was still under investigation. We can describe what restored service without treating it as a complete explanation of what broke.

For workarounds while repository access is unavailable, see the GitLab outage playbook.

Claude: errors across four products

15 September. Anthropic reported intermittent errors for Claude Mythos 5.1 and Fable 5.1. The affected products included Claude’s web app, API, Claude Code and Cowork. A fix was deployed, but the incident report does not explain the underlying fault.

For a developer using Claude Code, switching to the browser was not a dependable workaround: both were on the affected list. The report does not say every model or every request failed.

This illustrates a limit of backup options within one provider. Different interfaces can still depend on the same service. When choosing an alternative, the relevant question is whether it avoids the component that is failing. Our Claude outage playbook separates the web app, API and coding workflow.

Cursor: one model affected

15 September. Cursor initially named Composer and xAI in its updates. It later narrowed the impact to Grok 4.6, excluding the fast variant, and marked the incident resolved at 22:00 UTC. The official report does not describe the fault or fix.

The narrower update gave users something the initial report could not: a specific model and variant to avoid while investigating alternatives.

For applications offering several models, this is also a reason to measure failures per model. One overall success rate can conceal a failing model if most requests go to healthy ones. Recording the provider, model and variant alongside request outcomes helps distinguish those cases. That is a lesson for our own monitoring; Cursor’s report does not describe how its internal monitoring worked.

Cursor: cloud agents and dependent features

17 September. Cursor reported problems with Cloud Agents, Automations and Review Agents that depended on Cloud Agents. Bugbot was explicitly unaffected. The incident report recorded normal operation at 18:02 UTC and closed the incident at 20:04 UTC. These are update times, not exact outage boundaries.

A review that needs a cloud agent cannot run normally when that agent service is failing. Several affected features can therefore point back to one shared dependency. Their names in a product menu do not tell you how independently they operate.

The Bugbot exception mattered because it identified a feature outside the reported impact. Incident updates are more useful when they explain both what is failing and what remains available. The Cursor outage playbook distinguishes local editing from remote work.

At the arcade

Nines opens a browser arcade during qualifying official outages. Breach was the game played during these openings. The Hall of Fame records 145 submitted scores across five completed competitions:

Hall dateServiceSubmitted scoresWinner and score
15 SeptemberClaude15Simon: 27,400
15 SeptemberCursor7Seabmoby: 159,500
17 SeptemberCursor43Kartik: 142,500
18 SeptemberGitLab49Kartik: 180,200
19 Septembernpm31Uniboy: 176,000

Kartik won the GitLab competition, which offered a month of Claude Pro. Its 11-hour, 16-minute arcade window is not a measurement of GitLab’s downtime. Hall dates are competition dates; scores do not count every started game.

The npm entry links only to status history, so its triggering incident is unconfirmed. It appears in the results only.

Degraded banners alone do not unlock Nines. Get a ping for the next opening.