Skip to main content
A sandbox is not session-scoped. There are two separate limits, and only the first one is a time limit:
  • How long a sandbox can run continuously is capped by your plan.
  • How long a sandbox can stay paused is not capped at all. Paused sandboxes are kept indefinitely.

​
Continuous runtime limits

This is the time a sandbox can run without being paused. Pausing and resuming resets it, so a sandbox that pauses and resumes can be kept alive and reused for as long as you want. See Billing & limits.

​
What happens when the timeout expires

Every sandbox has a timeout, and it defaults to 5 minutes if you do not set one. Pass timeoutMs (JavaScript, milliseconds) or timeout (Python, seconds) to Sandbox.create() to change it, or call setTimeout() / set_timeout() on a running sandbox to reset the clock from that moment. What happens when the timeout expires is up to you, and the default is destructive:
  • onTimeout: 'kill' (the default) terminates the sandbox and releases its resources. A killed sandbox cannot be resumed, and its state is gone.
  • onTimeout: 'pause' pauses the sandbox instead. Both the filesystem and the memory are saved, which includes running processes and loaded variables.
Set autoResume to have a paused sandbox wake up on the next SDK call or HTTP request to one of its URLs.
Auto-pause is persistent. If the sandbox resumes and later times out again, it pauses again. See Persistence and AutoResume.

​
Paused sandboxes do not expire

Paused sandboxes have no time-to-live. There is no automatic deletion, no archiving, and no expiry after a fixed number of days. E2B never kills a paused sandbox on its own. A paused sandbox is removed only when you explicitly kill it:
While a sandbox is paused it is not billed and does not count toward your concurrency limit, so keeping paused sandboxes around costs nothing in compute or concurrency. See Do paused sandboxes count toward the concurrency limit?.