Is Claude Code Down? Sep 29 Outage and Oct 7 Spend Limit Bug
If Claude Code suddenly starts throwing errors, don't assume it's your network. As of October 2026, the official Claude status page has logged several incidents in the past three weeks that directly affect Claude Code: a broad error spike on September 29, a bug on October 7 that wrongly flagged some organizations as over their spend limit, and delayed credit top-ups on October 1. If your problem falls around those dates, Claude Code being down is probably not a configuration issue on your side. Below is a recap based on the official records, followed by a decision flow.
What happened on September 29?
According to the official incident page, the incident was titled "Elevated errors on claude.ai, Claude Code, Claude Cowork and the Claude API" and ran from 14:00 to 14:59 UTC on September 29 (22:00 to 22:59 Beijing time).
Timeline (all UTC):
- 14:21: Investigation began into elevated error rates on claude.ai, Claude Code, and Cowork, with a note that retrying might succeed.
- 14:28: Update added that some Claude API requests were also failing.
- 14:36: A mitigation was applied and error rates dropped noticeably (the 14:41 update said some login and session failures were still occurring).
- The 15:00 update added that a second issue was preventing many users from logging in (including SSO and Sign in with Apple), starting new conversations, using voice, making purchases, and uploading files. Claude Code and Cowork sessions were also affected.
- From 14:59 services returned to normal, and the incident was marked resolved at 16:27.
The official page specifically warns that some messages sent between 14:00 and 14:59 may not have been saved. If you had Claude Code running a long task during that window, check the results and your workspace changes. Don't assume it finished.
What was the October 7 spend limit issue?
According to the official incident page, "Issue with spend limits" was a bug in which some organizations were incorrectly judged to have hit their spend limit and were suspended, so their requests were rejected. Affected components were the Claude API, Claude.ai, Claude Code, Claude Security, and Cowork. The incident was marked resolved at 21:23 UTC on October 7.
The telltale sign of this kind of problem: your network is fine, other people's accounts may work normally, and only your organization is being rejected. If you're on an organization account and see a "spend limit reached" message while the console shows usage far below the limit, check the status page and contact official support. Don't keep retrying on your own.
What other related incidents were there?
From the official incident history:
- October 1, "Delayed credits on the Claude Platform": top-ups were credited late, so some API requests failed with insufficient-balance errors. Resolved at 22:36 UTC that day.
- "Elevated errors on platform.claude.com": first reported at 13:25 UTC on October 7 and marked resolved at 18:00 UTC on October 13. The Usage and Rate limits pages on platform.claude.com, plus usage reports in the Admin API, returned errors when loading data, and the most recent ~30 minutes of usage might show with a delay. The official note says API requests themselves were not affected.
The second item is easy to misread: a usage page that won't load does not mean the API is unavailable.
How do I match an error to its likely cause?
The table below lists common interpretations for troubleshooting. For exact error codes and wording, defer to the official error documentation.
| Symptom | Likely meaning | What to do first |
|---|---|---|
| 5xx, repeated timeouts | Likely a server-side problem | Check the status page for an active incident, wait, and retry |
| 429 | Rate or quota limit hit | Check your own usage and limits, and lower concurrency |
| 529 | Described in the official docs as service overloaded | Retry later and check the status page |
| Insufficient balance | An account balance issue, or possibly delayed credits (the October 1 incident) | Verify the console balance and top-up history |
| Spend limit reached | Could be real, or a false positive (the October 7 incident) | Compare console usage with the status page, and contact support if needed |
| Connection failure, certificate or DNS errors | Most likely your local network | Run a layered network check |
How do I tell an official outage from my own problem in three steps?
- Check external signals first. Open cdnping's /en/down/claude-code and /en/status/anthropic. The former combines the official status page, API probes every 5 minutes, and user reports; the latter probes the official API entry points from the Cloudflare edge. Then compare against status.claude.com, and treat the official page as authoritative.
- Then check your own network. Run a test to the Claude API on the cdnping home page, /en, and look at the time to first connection and the round trip. The first connection includes DNS and a TLS handshake. If it fails or is clearly slow here, the problem is most likely on your local path. For layer-by-layer troubleshooting, see How to troubleshoot Claude Code connection timeouts and errors.
- Finally, check your account. Log in to the console and verify your balance, usage, and spend-limit settings. For how quotas work, see Claude Max 5x vs 20x: what's the difference?
If there is an active official incident, wait for it to be marked recovered. Don't keep changing your configuration during an outage, since that only makes it harder to tell which step actually helped.
How can I find out about outages sooner?
The status page supports subscriptions, and the official incident history also offers an RSS feed (the history.rss used above). To see the last few months of incidents together, read AI service incidents roundup: September to October 2026. To understand incident severity levels and components, read How to read the OpenAI and Claude status pages.
On redundancy, a disclosure: cdnping has a commercial partnership with AGI Plan. AGI Plan is a multi-provider aggregation gateway that publishes hourly availability data per capability group (https://agiplan.dev/api/status/requests?month=YYYY-MM), and cdnping mirrors it at /en/status/agiplan. You can use that data to judge for yourself whether it meets your needs. Model availability is as listed at agiplan.dev/models, and it is not an officially authorized channel.
