--- title: "Cursor Not Working or 429 Errors? Oct 6–13 Status Review, 4 Checks" description: "Cursor's status page logged 25 resolved incidents from Sept 18 to Oct 16, with 429s on Oct 8. A recap plus a 4-step check to tell platform from upstream issues." url: https://cdnping.org/en/blog/cursor-429-degraded-october-2026 language: en published: 2026-10-18 category: "Service updates" tags: ["Cursor","429","status page","incident review","troubleshooting"] source: cdnping.org license: Free to quote and summarize with a link to the url above. --- # Cursor Not Working or 429 Errors? Oct 6–13 Status Review, 4 Checks If Cursor is down or keeps returning 429, it is often not your network or your account. Sometimes Cursor itself, or the model provider behind it, is having a problem. As of October 16, 2026, the [official Cursor status page](https://status.cursor.com/history.rss) recorded 25 resolved incidents between September 18 and October 16. October 6, 8, and 13 were the busiest days. Below is a walk through them in order, followed by how to tell which layer is failing. ## What kinds of incidents were these 25? Going by the status page descriptions, most were degradations of a single component or a single model, lasting anywhere from a dozen minutes to a few hours: | Type | Example | Notes | | --- | --- | --- | | Upstream model provider issue | Oct 6: degradation of a flagship Anthropic model | The status page notes a related external Claude status incident | | Model-side rate limiting | Oct 8: 429s on the same model | Affected all product components | | Platform components | Oct 13: errors in the IDE, Cloud Agents, Automations, and others | Multiple services affected at once | | Trigger-based services | Oct 13: tasks triggered by webhook, Slack, git, etc. did not run | See below | | Login and dashboard | Sept 18 | The status page attributes the cause to the authentication provider and says logged-in users were not expected to be affected | A few other incidents involved only one component, such as Cloud Agents or the Grok Bot. For the exact scope, see each incident's description. ## What happened on October 6 and 8? On October 6 the status page recorded 4 incidents. The earliest was errors on a flagship Anthropic model (12:40 to 16:00 UTC), and the status page linked to the external Claude status incident. Later that day, components such as Security Reviewer Agents and Cloud Agents also had periods of failure. October 8 had two incidents. From 13:54 to 15:31 UTC, the same model returned 429s, affecting all product components. From 19:52 to 20:51 UTC, there were intermittent errors and failed requests again. What these two days have in common is that the failures were tied to one model, so it is worth trying a different model. ## Why did some tasks "not run, with no error" on October 13? From 00:22 to 03:07 UTC on October 13, several services, including the IDE, Cloud Agents, and Automations, returned errors or failed requests. Another incident is easier to miss. According to the status page, from 10:52 to 13:29 Pacific Time on October 13 (17:52 to 20:29 UTC), routines triggered by webhook, Slack, git, email, Linear, and similar sources did not run. Webhook callers may have received an HTTP 400 with the message "Automation run rate limit exceeded", while other trigger types failed silently. Events sent during that window **are not retried automatically**, and the status page recommends resending any important events yourself. If you wired code review or deployment notifications to these triggers, events from that window need to be resent by hand. ## When Cursor errors out, how do you tell which layer is failing? Follow these four steps. It usually takes a few minutes to pin down: 1. **Check Cursor's own status.** Look at the [official Cursor status page](https://status.cursor.com) first, then cdnping's [/en/down/cursor](/en/down/cursor). cdnping syncs the Cursor status page every 15 minutes and also aggregates one-click user reports. 2. **Check the upstream provider.** If the error shows up on only one model, look at pages like [/en/status/anthropic](/en/status/anthropic) and [/en/status/openai](/en/status/openai). cdnping probes the official API entry points from the Cloudflare edge every 5 minutes. If the upstream has an open incident, that is most likely the cause. For help reading these pages, see [How to read the OpenAI and Claude status pages](/en/blog/how-to-read-ai-status-pages). 3. **Try a different model.** If other models work and only one fails, it is almost certainly a model-side problem. If every model fails, it looks more like the Cursor platform or your local network. For network problems, work through the [four-layer network checklist](/en/blog/claude-code-connection-troubleshooting). 4. **Check your own usage.** If the status pages are all clear and you are the only one being rate limited, look at the usage page in your Cursor account for your quota and limits. The exact location and rules are defined in the official documentation. ## What should you do when you hit a 429? A 429 means "too many requests or not enough capacity." Handle it in this order: - **Wait a bit, then retry.** For example, the October 8 429 incident took about an hour and a half from detection to resolution. Retrying repeatedly and immediately only makes congestion worse. - **Switch to another model or capability tier.** An incident from October 15 (affecting some models) mentioned capacity errors on some requests, and the status page suggested that retrying or switching models might help. Moving from a heavily loaded flagship model to a lighter tier usually still lets you keep coding day to day. - **Check whether it is your own quota.** Unlike a global outage, hitting your usage cap affects only you. - **Do not give automated jobs unlimited retries.** Use exponential backoff and keep failure logs so you can resend events afterward. For how other services fared in the same period, see [AI service incidents, September to October 2026: OpenAI and Claude outage statistics](/en/blog/ai-service-incidents-sep-oct-2026) and [Frequent Codex errors in October](/en/blog/codex-outages-october-2026-capacity). ## Sources - [Cursor status page incident history (2026-09-18 to 2026-10-16)](https://status.cursor.com/history.rss) Incident times follow the official status page and are in UTC unless marked as Pacific Time. cdnping and AGI Plan have a business partnership; this article does not cover any AGI Plan products.