VM and CMK cluster creation issue in us-east2 region
This incident has been resolved.
The latest update from Crusoe.
State
Resolved
Started
61 d ago
2026-09-02 08:22 UTC
Lasted
7 h 35 min
until 2026-09-02 15:57 UTC
Worst impact
Degraded
Timeline
6 updatesInvestigating
5 h 18 min 70%
Monitoring
2 h 17 min 30%
Updates
Times in UTCAs posted by Crusoe
This incident has been resolved.
We've identified the cause of the errors when creating/starting VMs or creating scaling CMK clusters in us-east2 region and applied a fix. We'll continue monitoring.
We continue investigating "insufficient capacity" errors when creating/starting VMs or creating scaling CMK clusters in us-east2 region. We'll share an update as soon as we have more information available.
We continue investigating "insufficient capacity" errors when creating/starting VMs or creating scaling CMK clusters in us-east2 region. We'll share an update as soon as we have more information available.
We continue investigating "insufficient capacity" errors when creating/starting VMs or creating scaling CMK clusters in us-east2 region, and have narrowed down a likely cause. We'll share an update as soon as we have more information available.
We are investigating "insufficient capacity" errors when creating/starting VMs or creating scaling CMK clusters in us-east2 region. Existing VMs continue to run normally. We'll share an update as soon as we have more information available.
Crusoe in the last 90 days
Full historyIncidents in 90 days
5
Days with an incident
9
Median duration
3 h 54 min
This incident
1.9× the median
Other Crusoe incidents
All incidentsCrusoe·Facility issue in us-east2-a
This incident has been resolved.
Crusoe·Storage accessibility issues in eu-norway1
This incident has been resolved.
Crusoe·A subset of VMs are showing as UNSPECIFIED in our us-east2 region
This incident has been resolved.
Crusoe·Networking issue affecting service connectivity
We identified general network errors affecting service connectivity in our us-east1 region. The issue has been resolved and services are operating normally.
Follow Crusoe
Your coding agent knows when Crusoe is down, and tells you when a failure is theirs, not yours. You can also get Crusoe incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "crusoe" and tell me if Crusoe has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=crusoe/feed subscribe https://outages.cc/feed.xml?providers=crusoeFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane