Where does this status come from?

From Cursor's own status page API at https://status.cursor.com. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are Cursor's words.

How can my agent or app check Cursor status?

Fetch https://upbutler.com/status/cursor/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"cursor"}, on https://upbutler.com/mcp/public.

How do I know whether an outage is mine or Cursor's?

Add "cursor" to the dependencies of your UpButler workspace. When one of your monitors fails while Cursor has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

Is Cursor down?

Right now

No. Cursor is operational.

No incidents reported.

Read from status.cursor.com 15 s ago · every 120s

For agents

proceed

Proceed.

GET upbutler.com/status/cursor/status.agent.json

MCP: upstream_status {"service":"cursor"}

The Cursor editor, its agents and background agents API.

What Cursor reports

Operational

Taken as is from Cursor's own status page API. Incident titles and component names below are theirs.

Open status.cursor.com

UpButler's independent probe

There is no keyless endpoint of Cursor that says anything useful, so UpButler does not probe it. To check your own Cursor account, add a monitor with your key: it is yours alone and catches what a shared probe cannot.

Cursor components

8 operational

AutomationsOperational
Review AgentsOperational
CLIOperational
Cloud AgentsOperational
cursor.comOperational
IDEOperational
OriginOperational
Grok BotOperational

Cursor incidents, last 90 days

13 finished incidents seen since UpButler started tracking on 2026-10-10, 4 of them rated major or critical by Cursor. A typical one lasted 58 min; the longest 3 h 41 min.

Started (UTC)	Incident	Impact	Lasted
2026-10-09 22:37	Investigating service degradation — Cloud Agents and Grok Bot	minor	31 min
2026-10-09 21:31	Investigating service degradation — Cloud Agents	minor	12 min
2026-10-08 19:52	Elevated errors affecting Opus 5.5	minor	58 min
2026-10-08 13:54	Opus 5.5 is Experiencing 429s	minor	1 h 37 min
2026-10-07 15:59	Investigating service degradation — Grok Bot	minor	1 h 26 min
2026-10-06 22:48	Investigating service degradation — Cloud Agents	major	17 min
2026-10-06 19:27	Investigating service degradation — Cloud Agents and Grok Bot	major	2 h 39 min
2026-10-06 17:49	Investigating service degradation — Security Reviewer Agents	major	1 h 7 min
2026-10-06 12:40	Elevated errors affecting Anthropic models	minor	3 h 20 min
2026-10-03 06:50	Investigating service degradation — Grok Bot and Review Agents	minor	36 min
2026-09-29 19:43	Investigating service degradation - xAI models	major	35 min
2026-09-29 14:25	Investigating service degradation — Cloud Agents and Grok Bot	minor	3 h 41 min
2026-09-28 20:23	Investigating service degradation — Grok Bot	minor	13 min

Tell your outage from Cursor's

Declare that your project depends on Cursor. When one of your monitors fails while Cursor has an incident that began around the same time, UpButler tags your incident "likely upstream" with their incident linked, says so in the alert and the AI report, and tells your on-call agent not to change code.

npx upbutler init finds the dependency from your env var names and packages. The catalog, dependencies and upstream-aware incidents are on every plan, including Free.

Start free How it works

upbutler.yaml

# upbutler.yaml
dependencies:
  - cursor

Ask before you retry

curl -s https://upbutler.com/status/cursor/status.agent.json

status.agent.json (live)

{
  "schema": "upbutler.upstream-status/v1",
  "service": "cursor",
  "verdict": "proceed",
  "status": "operational",
  "reason": "No incidents reported",
  "retryAfterSec": null,
  "incident": null,
  "probe": null
}

Questions

Is Cursor down right now?: No. As of 2026-10-10 05:10 UTC, Cursor is operational. This page reads the status again every 2 minutes.
Where does this status come from?: From Cursor's own status page API at https://status.cursor.com. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are Cursor's words.
How can my agent or app check Cursor status?: Fetch https://upbutler.com/status/cursor/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"cursor"}, on https://upbutler.com/mcp/public.
How do I know whether an outage is mine or Cursor's?: Add "cursor" to the dependencies of your UpButler workspace. When one of your monitors fails while Cursor has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

More in ai models and tooling

UpButler is not affiliated with Cursor. Status and incident text belong to Cursor and are read from their public status source; the probe result is UpButler's own measurement.