Cursor was hit by a global “high demand” outage on July 16, 2026, returning ERROR_RESOURCE_EXHAUSTED errors that blocked AI requests for just over two hours. StatusGator caught it early, sending an Early Warning Signal at 06:49 UTC, 12 minutes before Cursor acknowledged the incident at 07:01 UTC. Here is the full picture, including the workaround that kept many users coding.
Incident at a glance
| Detail | Value |
|---|---|
| Service | Cursor |
| Date | July 16, 2026 |
| Status | Resolved |
| Duration | ~2 hours 5 minutes |
| Primary symptom | “High demand” / ERROR_RESOURCE_EXHAUSTED |
| Affected surfaces | AI model requests across the IDE |
| First user report | 06:39 UTC |
| StatusGator Early Warning Signal | 06:49 UTC |
| Provider acknowledged | 07:01 UTC |
| Recovery | 08:44 UTC |
| Detection lead | 12 minutes before acknowledgment |
Was Cursor down on July 16, 2026?
Yes, though it was a high-load event rather than a total blackout. Cursor stayed open, but from about 06:39 UTC to 08:44 UTC its AI requests failed or stalled behind “We’re experiencing high demand” errors. For most developers, that is functionally the same as being down, since the AI features are the point.
What caused the Cursor outage?
The root symptom was resource exhaustion, or model capacity being overwhelmed. Users saw the error ERROR_RESOURCE_EXHAUSTED with the title “High Load,” surfaced as “We’re experiencing high demand right now. Please try again in a few moments.” A subset also saw “Unable to reach the model provider,” pointing to trouble routing requests to the underlying models.
Notably, the load appeared concentrated on specific models that were being auto-selected, which is why switching models worked around it for many users (more on that below).
How long was Cursor down?
The disruption lasted roughly 2 hours and 5 minutes, from the first user report at 06:39 UTC to the last one at 08:44 UTC. Cursor acknowledged the issue early on, at 07:01 UTC, and the errors gradually eased before recovery.
Timeline of the July 16 Cursor outage (UTC)
| Time (UTC) | Event |
|---|---|
| 06:39 | First outage reports reach StatusGator (Brisbane, Australia: “Error: High Load”) |
| 06:39 to 06:48 | Reports climb fast, dominated by “high demand” and “high load” errors from India, Kenya, the UAE, and Sweden |
| 06:49 | StatusGator sends an Early Warning Signal to subscribers |
| 07:01 | Cursor acknowledges the issue on its status page, 12 minutes after StatusGator’s alert |
| 07:01 to 08:29 | Errors persist, later shifting toward sign-in problems as the incident wound down |
| 08:44 | Final outage reports arrive; recovery |
Who was affected?
The reports clustered heavily in India and across Asia, and the timing explains why. The incident ran from 06:39 to 08:44 UTC, which is roughly noon to 2 p.m. in India and mid-afternoon across much of Asia, peak coding hours. Reports poured in from Hyderabad, Bengaluru, Chennai, Surat, Jaipur, Kochi, and Ahmedabad, alongside Pakistan, Sri Lanka, Malaysia, the Philippines, and the UAE, with a lighter scatter across Europe and North America.
The pattern is worth remembering: a “high demand” outage bites hardest wherever demand is highest at that moment, so teams working in those hours feel these events first and worst.
A snapshot of what users reported, from around the world:
- “We’re experiencing high demand right now. Please try again in a few moments.” (the most common report by far)
- “ERROR_RESOURCE_EXHAUSTED” (Kuala Lumpur, Malaysia)
- “Unable to reach the model provider” (Beaverton, Oregon)
- “unable to connect the model” (Chennai, India)
- “cant use even auto” (Parañaque City, Philippines)
- “not working. it shows experiencing high demand right now.” (Dubai, UAE)
The workaround: how users kept coding
A useful pattern surfaced in the reports. Because the high load was concentrated on specific auto-selected models, switching models restored service for many people. One report from Pakistan quoted Cursor’s own prompt: “We’re experiencing high demand for Cursor Grok 4.5 right now. Please switch to Auto, another model, or try again.” A user in Denmark went further, advising others to move off Auto to a specific model because the auto-router kept landing on the overloaded one.
If you hit a Cursor high-load error, this is worth trying:
- Switch from Auto mode to a specific model that is not under load.
- If one model is throttled, try a different provider or model family.
- Retry after a short pause, since these errors are marked retryable.
None of this fixes the provider’s capacity issue, but it can keep you productive while the incident is resolved.
How did StatusGator detect the outage early?
StatusGator sent its Early Warning Signal at 06:49 UTC, 12 minutes before Cursor’s official acknowledgment at 07:01 UTC. It works by pairing official status feeds with real-time user reports, so a sudden spike in unofficial reports can trigger an alert before the provider confirms anything.
In a high-load event, that speed is the whole point. These outages escalate in minutes, and the sooner your team knows, the sooner you can switch models, pause CI jobs that call the API, or tell developers to hold off. For historical context, you can review Cursor’s outage history and the Cursor outage map to see how often these events happen and where they land.
Frequently asked questions
Was Cursor down on July 16, 2026?
Cursor was not fully offline, but it returned “high demand” and ERROR_RESOURCE_EXHAUSTED errors worldwide from about 06:39 to 08:44 UTC, which blocked most AI requests. For live status, check the Cursor status page on StatusGator.
What does “We’re experiencing high demand right now” mean in Cursor?
It means Cursor’s model capacity is temporarily exhausted (ERROR_RESOURCE_EXHAUSTED). The request is retryable, and switching to a less-loaded model often works around it.
How long did the Cursor outage last?
About 2 hours and 5 minutes, from the first user report to the last.
How can I get warned about Cursor outages early?
Monitor Cursor with StatusGator and turn on Early Warning Signals, which alert you when user reports spike ahead of the official acknowledgment.
Monitor Cursor with StatusGator
If your team codes in Cursor, a high-load event can stall everyone at once. StatusGator combines official status pages with real user reports and sends Early Warning Signals the moment a pattern emerges, often minutes before the provider confirms anything.
Start monitoring with StatusGator and get early warnings for the services your team depends on.
