# E2B sandbox concurrency control room and capacity planner

> See how much room is left under your E2B concurrency ceiling, reclaim the least defensible sandboxes by hand, and decide when to buy more capacity.

- Workflow type: app
- Services: E2B, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-21

## What it does

- A headroom gauge at the top of the screen shows how many sandboxes are running right now against the ceiling on your plan, filling and turning red as you close in on it.
- A live table lists every running sandbox with its age, template, owner or job, time left before it expires, and current CPU and memory, sorted so the weakest claims on a slot rise to the top.
- Pause, Kill and Extend buttons on every row, plus multi-select for a bulk reclaim behind a confirmation step. Nothing is ever reclaimed for you.
- A history tab rebuilds peak concurrency day by day, and a Draft the capacity case button hands those peaks to a background agent that writes a recommendation memo and posts it to Slack.

## What you'll need

- An E2B account and an API key for the team whose sandboxes you want to watch
- The concurrent sandbox limit on your current E2B plan, which you enter once in app settings
- A Slack workspace, if you want the capacity memo posted to a channel

## Prompt

Build me a control room for E2B sandbox concurrency. My team's E2B plan has a hard ceiling on how many sandboxes can run at once, and when we hit it new sandboxes stop launching for real customers. I need one screen that shows how much headroom is left and lets a human decide what to reclaim. This is a staffed decision surface, not an automation: nothing is ever paused or killed unless someone clicks a button.

The concurrency ceiling has to be a setting. The E2B API does not tell the app what our plan allows, so app settings should hold the ceiling as a number I type in (20 on Hobby, 100 on Pro, higher with purchased add-ons), plus the two thresholds where the headroom gauge changes color (default warning at 70 percent and critical at 85 percent), the default extension length used by the Extend button, the Slack channel the capacity memo is posted to, and which sandbox metadata keys should be read as owner and job. Persist these for the app so everyone on the team sees the same ceiling.

The first tab is the live floor. At the top, a headroom gauge: running sandboxes right now versus the ceiling, shown as a big number, a percentage, and a band that fills and turns amber then red as we approach the limit. Get the running count from List Sandboxes filtered to running state, following the cursor pagination until there are no pages left so the count is accurate rather than capped at a single page. Show the paused sandbox count alongside it, since paused sandboxes do not hold a concurrency slot but their snapshots do keep consuming storage.

Below the gauge, one row per running sandbox, built from List Sandboxes joined to List Sandboxes Metrics batched over the sandbox IDs on screen. Each row shows the sandbox ID, how long it has been alive, its template, the owner or job pulled from the sandbox metadata, the time left on its TTL as a live countdown, and current CPU and memory. Sandbox metadata is free-form, so use the key mapping from settings and fall back to displaying the raw metadata when nothing matches. Clicking a row opens a detail drawer backed by Get Sandbox.

Sort so the least defensible slot holders float to the top. Rank rows by a reclaim score that combines near-zero CPU across the most recent metrics samples, greatest age, and how many times the sandbox has been extended, counting refresh and timeout events per sandbox from the lifecycle history. Show the reason each row ranked where it did in plain words, something like 'idle 40 minutes, 6 hours old, extended 4 times', so I can defend the call to whoever owns it. Let me re-sort by any column and filter by template or owner.

Every row gets Pause, Kill and Extend. Pause calls Pause Sandbox, Kill calls Kill Sandbox, and Extend calls Set Sandbox Timeout with the default from settings, or Refresh Sandbox when I only want to reset the existing TTL. Make Pause the visually primary action, because it snapshots filesystem and memory and the sandbox can be resumed later. Treat Kill as destructive: red styling, a confirmation that states plainly that the sandbox cannot be recovered, and never the default. Next to the Extend control, note that a timeout is measured in seconds from now and replaces the existing TTL rather than adding to it, and that plans cap it at 3600 seconds on Hobby and 86400 seconds on Pro.

Add checkbox multi-select with a bulk reclaim bar. Selecting rows shows how many slots the action would free and what the gauge would read afterwards, then a confirmation step that lists every affected sandbox by ID, owner and age before anything runs. Bulk Pause and bulk Kill both go through that step, with Kill requiring an explicit typed confirmation. Run the calls one sandbox at a time, show per-sandbox success or failure, and refresh the gauge when the batch finishes. Pausing takes roughly four seconds per GiB of RAM, so show progress instead of freezing the screen.

The second tab is peak concurrency history. Page through List Team Sandbox Lifecycle Events and replay created, resumed, paused and killed events in time order to reconstruct how many sandboxes were running at each moment, then chart the daily peak against the ceiling line so I can see how close each day actually got. Break the peaks down by template and by owner so I can see what drives them. That data is offset paginated at a maximum of 100 events per page, so the window is bounded: state on screen the earliest event the app could reach and say the history starts there, rather than implying it covers all time.

Put a 'Draft the capacity case' button on the history tab that kicks off a background agent. The agent reviews the reconstructed peaks, the template and owner breakdown, and the current live table, then works out which of two stories is true: we are genuinely growing into the ceiling and should buy capacity, or we are leaking abandoned sandboxes and should fix the code that forgets to close them. It writes a short memo either way, no longer than a page, naming the evidence, the peak days, the templates and owners responsible, and one clear recommendation. Save the memo in the app so past memos stack up in a list I can reopen and compare, and post it to our platform channel using the Slack Send a Message operation with the channel from settings. Show the run status on the button, and drop the finished memo into the list when it lands.

Keep the whole surface focused on headroom and capacity decisions rather than idle cleanup. Refresh the live tab on an interval and on demand, show when the data was last fetched, and if E2B returns a rate limit error, surface it plainly, since that is the same failure our customers hit when we run out of slots.

## How to customize

- Set your plan ceiling and the points where the gauge shifts from healthy to warning to critical
- Change how the table ranks reclaim candidates, for example weighting idle CPU more heavily than age
- Pick the Slack channel the capacity memo goes to and how many days of history the agent reviews
- Map which sandbox metadata fields hold the owner and the job name, so rows read in your team's language

## FAQ

### Does this shut down sandboxes automatically?

No, and that is the point. Every pause, kill and extension happens because a person clicked a button. The app ranks candidates and shows you the evidence, but the decision stays with you, which is what you want when a sandbox might belong to a paying customer's live session.

### What is the difference between pausing and killing a sandbox?

Pausing takes a snapshot of the sandbox, including its memory, and frees up the concurrency slot. You can bring it back later, and snapshots are kept for up to 30 days. Killing is permanent and unrecoverable. The app makes Pause the default action and puts a clear warning behind Kill.

### Why do I have to type in my plan limit?

E2B does not report your plan's concurrency ceiling back to the app, so you enter it once in settings and every view measures against it. If you buy a capacity add-on or change plans, update the number in settings and the gauge and history charts adjust.

### How far back does the peak concurrency history go?

It goes back as far as the sandbox activity history the app can read, which is a bounded window rather than all time. The app tells you the earliest moment it could reach and labels the chart accordingly, so you never mistake a partial window for your full history.

### If I extend a sandbox, does the extra time get added to what it already had?

No. A new timeout is counted from the moment you click and replaces whatever was set before, so extending a sandbox that had two hours left to a one hour timeout shortens it. The app spells this out next to the Extend control. Plans also cap the maximum, at one hour on Hobby and 24 hours on Pro.

Use this prompt in General Input: https://www.generalinput.com/prompts/e2b-sandbox-concurrency-control-room-and-capacity-planner