Degraded performance: API and sandbox operations
Daytona reports degraded performance on app.daytona.io and sandbox creation. Some API requests and sandbox operations are slow or time out. Daytona identified the queries involved and works to restore normal performance. Running sandboxes are not affected.
State
Degraded
Started
Ongoing for
1 h 28 min
Worst impact
Degraded
Timeline
1 updateDegraded
1 h 28 min 100%
Updates
Times in UTCAs posted by Daytona
We're seeing degraded performance in our database, so some API requests and sandbox operations (create, start, stop, delete) are slower than usual or timing out. We've found the queries involved and are working to restore normal performance. Running sandboxes are not affected. We'll post another update within 30 minutes.
Affected components
2Daytona in the last 90 days
Full historyIncidents in 90 days
11
Days with an incident
8
Median duration
36 min
This incident
2.5× the median
Other Daytona incidents
All incidents
Daytona·Major outage
Daytona reports a major outage on app.daytona.io. Daytona later reported that the problem is resolved. The outage lasted 3 minutes.
Daytona·Major outage
Daytona reports a major outage on app.daytona.io. The incident is resolved. It lasted 9 minutes, from 13:15 to 13:24 UTC on 3 November 2026.
Daytona·Degraded performance for a subset of US runners
All of the nodes in the US Region that were impacted have been fully recovered.
Daytona·Sandbox listing (GET /sandbox)
An issue in our data indexing pipeline delayed updates to the sandbox list between 22:42 UTC on October 29 and 06:30 UTC on October 30, so recently created, changed or deleted sandboxes may not have appeared correctly in list results during that time. Sandbox operations themselves were not affected, and no data was lost. The pipeline has been restored, all pending updates have been processed, and the sandbox list is now fully up to date.
Daytona·US Region Runner Degradation
All of the nodes in the US Region that were impacted have been fully recovered
Follow Daytona
Your coding agent knows when Daytona is down, and tells you when a failure is theirs, not yours. You can also get Daytona 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 "daytona" and tell me if Daytona 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=daytona/feed subscribe https://outages.cc/feed.xml?providers=daytonaFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane