Hour-long workflow runs and automatic sandbox failover

Long runs used to stop for reasons that had nothing to do with the work. Code workflows were capped at 5 minutes and chat and scheduled runs at 10, a deploy could stop a worker mid-run, and a sandbox provider having a bad hour meant failed runs. Over May we lined all of those up.

How it works

• One 60-minute limit. Chat, scheduled runs, resumes, follow-ups, and code workflows share a single 60-minute timeout. A run that hits it is recorded as timed out, separately from a cancel, and the error states the limit.
• Deploys drain instead of killing. On shutdown, a worker stops taking new jobs and finishes the ones it has, for up to an hour, so a deploy no longer cuts off a long run or its final file save.
• Autoscaling. The worker pool scales with load, waiting before scaling up so brief spikes don't overreact and before scaling down so bursts can finish.
• Two sandbox providers. Sandboxes run on E2B or a second provider, built from one shared image so every run sees the same packages, fonts, and tools.
• Failover. If the primary provider errors or isn't ready within its deadline (10 seconds by default), the run moves to the next provider automatically.