Live - 300+ check locations
Is Cursor down right now?
HostTracker's monitoring network reached cursor.com and completed a full check without errors. It has been up for 40d 0h.
Stop finding out from a search - HostTracker's website monitoring checks the services you depend on from 300+ locations and alerts you the moment one changes.
Up
for 40d 0h
- Last check
- just now
- Next check
- -
- HTTP
- OK
Checking cursor.com right now
A fresh check, started when you opened this page - each probe runs its own independent DNS, TCP, TLS and HTTP request. Anonymous runs sample the network; a signed-in account checks from more locations.
Cursor status
What Cursor's own status page reports - separate from HostTracker's own checks above.
Operational according to Cursor's status page, updated just now
No open incidents on Cursor's status page.
Cursor parts
11 parts on its status page- Cursor IDE (iOS)
- IDE
- Cloud Agents
- CLI
- Automations
- BugBot
- Review Agents
- Grok Bot
- cursor.com
- Origin
- Enterprise Dashboard
Last 90 days on Cursor's status page
The newest 1063 incidents: 1 critical, 16 major, 45 minor and 1 not rated.
- Multiple services degraded Minor impact 44m
- Auto Review Degradation Minor impact 1h 36m
- Cloud Agent Degradation Minor impact 7h 42m
- Investigating Service Degradation with VS Code Extensions Minor impact 9h 34m
- Degraded performance - Origin and Cloud Agents Minor impact 17m
- Multiple services degraded Major impact 1h 58m
- Delayed responses in Grok Bot Major impact 10m
- Elevated errors affecting repository integrations Not rated 46m
- Payment System Sync Issues Minor impact 5m
- Degraded agent personalization and codebase sync Minor impact 3h 17m
HostTracker is not affiliated with Cursor. Incident text is quoted briefly from their status page, with a link to the full post.
Want this on Slack, Teams, SMS or email, only for the parts you use? See Vendor Watch below.
How Cursor has behaved
Every figure here comes from HostTracker's own checks of cursor.com, not from the vendor's status page.
Response time
382ms avg · 7408ms peak
What we check
-
HTTP380 ms average, every 10 minutesOK
-
Ping13 ms average, every 10 minutesOK
-
Page Speed2168 ms average, every 15 minutesOK
90-day uptime
100.000% over 41 measured days · 0 incidents
- Operational
- Degraded
- Down
- No data
Incident history
Last 90 daysNo incidents recorded in the last 90 days.
Get alerted the next time Cursor goes down
One alert per incident, on Slack, Teams, SMS or email, and only for the parts you use. To start, we pre-select IDE and Cloud Agents.
- Cursor's own post, linked and quoted
- Problem reports from people on this page
30-day trial, no card. Cursor comes pre-selected - nothing is watched until you press Start watching.
Already have an account? Sign in
HostTracker is not affiliated with Cursor.
Is Cursor not working for you?
Tell us what is broken. One click, no account.
One report per visitor per hour. We keep only the country and the problem type, never your IP address.
Problem reports, last 24 hours
Reports come from visitors of this page. A sharp rise above the usual level, together with failed checks in the live check below, means the problem is on Cursor's side, not yours.
Top reported problems
Share of reports in the last 2 hours.
About Cursor outages
Written by the HostTracker monitoring team · updated from live probe data.
Cursor is an AI-powered code editor built on top of familiar editing tools, with its AI features - chat, inline edits, autocomplete - running through its own backend at api2.cursor.sh rather than purely on the model it happens to be using for a given request. That layering means an outage can originate in more than one place: Cursor's own request-handling infrastructure, or the specific upstream model provider it's routing a request to at that moment. The editor itself keeps working as a text editor even when the AI layer is unreachable, which can mask a real incident - files open and save normally while chat and inline suggestions quietly stop responding, so the AI features failing isn't always obvious from the interface alone.
Common causes of Cursor downtime
Not sure whether it's Cursor or your own connection? Read the full breakdown in our website down checker guide for a general walkthrough of diagnosing any outage, from DNS failures to expired certificates.
Incidents at the upstream model providers Cursor routes requests to, which can degrade AI features without any problem in Cursor's own infrastructure
Request queueing at peak hours, when heavy demand for chat and inline completions produces slow responses or timeouts rather than a clean failure
Authentication problems that block sign-in to a Cursor account while the editor itself continues to function as a plain code editor
Extension and editor updates that temporarily break the connection between the client and its backend until the update completes
Other services we track
HostTracker has monitored websites and online services since 2004 and is trusted by 500,000+ sites today, covering 14 check types from 300+ global locations. Want the same multi-location confirmation and instant alerts for your own site or any service you depend on? Getting started costs nothing - start a free monitor or compare plans and pricing.
Questions people ask during an outage
The live probe run on this page tests cursor.com from a broad sample of HostTracker's 300+-location monitoring network - many independent networks at the same moment, rather than just your own connection. If every location fails to reach it, the outage is real and affects everyone; if only a few locations fail while most load normally, the problem is local to those regions or networks rather than Cursor being fully down. A single refresh from your own browser can never make that distinction, because it only ever tests from one vantage point on one network.
Yes. HostTracker lets you add any URL - including third-party services you depend on, not just your own website - as a monitored target, and notifies you automatically the moment it becomes unreachable. Before sending an alert, HostTracker re-verifies a failure from multiple locations in its 300+-location network, so you're notified about real, confirmed outages rather than a single location's momentary blip. The free plan checks two monitors every 30 minutes indefinitely at no cost; paid plans check as often as once a minute, with alerts available through SMS, email, voice call, and several messenger apps.
No - as of the most recent check, cursor.com is responding normally to HostTracker's monitoring network, and has been up for 40d 0h. Over the last 24 hours it recorded 100.00% uptime across 0 incidents. If it is failing for you specifically, the cause is local - your network, DNS cache, or a regional route - and the live probe results above will show which locations, if any, are affected.
No - as of the most recent check, cursor.com is responding normally to HostTracker's monitoring network, and has been up for 40d 0h. Over the last 24 hours it recorded 100.00% uptime across 0 incidents. If it is failing for you specifically, the cause is local - your network, DNS cache, or a regional route - and the live probe results above will show which locations, if any, are affected.
No - as of the most recent check, cursor.com is responding normally to HostTracker's monitoring network, and has been up for 40d 0h. Over the last 24 hours it recorded 100.00% uptime across 0 incidents. If it is failing for you specifically, the cause is local - your network, DNS cache, or a regional route - and the live probe results above will show which locations, if any, are affected.
Very likely, and it's a distinctive pattern for Cursor specifically. Because Cursor is a full code editor with AI features layered on top rather than an AI tool with an editor attached, the base editing experience - opening, editing and saving files - keeps working even when the AI backend is down. So a silent AI layer with a perfectly normal editor around it is exactly what a backend incident looks like from the user's side, not evidence that the problem is local to your setup.
Not always. Cursor's AI features are served through its own backend at api2.cursor.sh, which in turn calls out to the model providers behind chat and completions, so a failure can sit in either layer. If a specific model or feature is failing while others in Cursor work fine, the fault is more likely upstream; if everything AI-related stops at once across different models, that points at Cursor's own infrastructure. This page checks cursor.com's reachability, a useful signal either way.
Heavy simultaneous demand for chat and inline completions can queue requests at Cursor's backend during peak hours, producing longer waits or occasional timeouts without the service being fully unreachable. This is ordinary load behaviour rather than a fault and tends to ease outside busy periods. Persistent failures that don't improve, or a complete lack of response over an extended stretch, are more likely a genuine incident worth checking against a live status result.