Elevated error rates and slower sandbox start times
Sandbox start times and error rates have returned to normal and the incident is fully resolved.
The latest update from E2B.
State
Resolved
Started
59 d ago
2026-09-03 00:02 UTC
Lasted
15 min
until 2026-09-03 00:18 UTC
Worst impact
Degraded
Timeline
3 updatesInvestigating
11 min 73%
Identified
4 min 27%
Updates
Times in UTCAs posted by E2B
Sandbox start times and error rates have returned to normal and the incident is fully resolved.
We have identified the cause of the elevated errors and resolved the issue. An internal caching layer is under heavy load due to an unusually high volume of running sandboxes, and our infra team is working on the fix.
We are currently investigating elevated error rates and increased sandbox start times. Some users may experience failed requests or slower-than-usual sandbox creation. Our team is actively working on it and we will post an update shortly.
E2B in the last 90 days
Full historyIncidents in 90 days
11
Days with an incident
10
Median duration
1 h 41 min
This incident
85% shorter than the median
Other E2B incidents
All incidents
E2B·Intermittent template build errors on US-West-1
The issue has been fully resolved. We apologize for the disruption. If you are still seeing issues, please let us know.
E2B·Increased errors on sandbox pause.
This incident has been resolved. Sandbox pause and resume are working normally.
E2B·Elevated error rates when creating sandboxes from snapshots
This incident has been fully resolved. We’ll publish a postmortem soon with more details on the cause and resolution. We apologize again for the disruption.
E2B·Elevated error rates and slower sandbox start times
This incident has been resolved. Sandbox creation and API error rates are back to normal. We apologize for the disruption.
E2B·Elevated template build failures
The build failures have been resolved.
Follow E2B
Your coding agent knows when E2B is down, and tells you when a failure is theirs, not yours. You can also get E2B 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 "e2b" and tell me if E2B 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=e2b/feed subscribe https://outages.cc/feed.xml?providers=e2bFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane