Degraded performance: API and sandbox operations
Daytona reported degraded performance on app.daytona.io and sandbox creation. Some API requests and sandbox create, start, stop, and delete operations were slow or timed out. Daytona resolved the incident, which lasted about 103 minutes.
State
Resolved
Started
Lasted
1 h 43 min
Worst impact
Degraded
Timeline
2 updatesDegraded
1 h 43 min 100%
Updates
Times in UTCAs posted by Daytona
Between 13:05 and 14:40 UTC, the Daytona API had elevated latency and intermittent errors. Some sandbox create, start and stop operations were slow or failed during this window. The cause was a database overload brought on by an unusually high volume of repeated requests, which kept routine database maintenance from completing. We restored the database and confirmed that performance is back to normal. We're adding safeguards so a single source of traffic can't cause this again. If any of your sandboxes are still in an unexpected state, retry the operation or contact support.
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
41 min
This incident
2.5× the median
Other Daytona incidents
All incidents
Daytona·Major outage
Daytona reports a major outage on app.daytona.io. The incident is resolved. It lasted 6 minutes.
Daytona·Major outage
Daytona reports a major outage on app.daytona.io. The incident is resolved. It lasted 9 minutes.
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.live/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.live/feed.xml?providers=daytona/feed subscribe https://outages.live/feed.xml?providers=daytonaFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane