Auto-kill idle E2B sandboxes and post hourly Slack triage

Every hour, scan my E2B fleet for runaway sandboxes that are quietly burning money and post a triage report to Slack.

Start by calling E2B's List Sandboxes with state=running to get every active sandbox in my team. For each sandbox that has been alive for more than 2 hours, call Get Sandbox Metrics over the last 15 minutes so you can see CPU and memory usage. Also pull recent lifecycle events for those long-lived sandboxes so you can tell which ones have not been touched in a while.

Then decide which sandboxes look stuck versus legitimately busy. Signals for stuck: alive for several hours, sustained near-zero CPU across the metrics window, no recent lifecycle updates, and metadata that suggests a one-off job rather than a long-running service. Signals for legit: meaningful CPU or memory activity, recent lifecycle events, or a template and metadata that imply a long-running workload.

For any sandbox that has been idle for over an hour (alive more than 1 hour with near-zero CPU and no recent lifecycle events), call Kill Sandbox to terminate it and mention in the report that you killed it.

Finally, post a single message via Slack Bot's Send a Message to my engineering channel. Open with a one-line summary I can skim on mobile: how many sandboxes are running, how many look suspicious, and how many you auto-killed. Then list each suspect with sandbox ID, age, current CPU and memory, template name, and metadata tags (especially userId, PR, or job tags so I know who to ask). Clearly mark which entries were auto-killed versus flagged for review.

Context worth knowing: E2B Hobby plan defaults to a 5-minute sandbox TTL and maxes out at 1 hour; Pro plan tops out at 24 hours. A sandbox sitting at near-zero CPU for over an hour with no recent lifecycle events is almost always forgotten, and the metadata tags are usually the fastest way to find the owner.

Additional information

What does this prompt do?

Every hour, checks every running sandbox in your E2B team and pulls recent CPU and memory usage for the long-lived ones.
Decides which sandboxes look stuck (alive for hours with near-zero activity, no recent lifecycle updates) versus the ones doing real work.
Posts one Slack message with a phone-friendly summary line plus details for each suspect: sandbox ID, age, current CPU and memory, template, and metadata tags like userId, PR, or job.
Automatically shuts down any sandbox that has been idle for over an hour and calls it out in the same report.

What do I need to use this?

An E2B account with an API key from your team dashboard.
A Slack workspace and a channel where the report should land.
Optional but recommended: a habit of tagging sandboxes with metadata such as userId, PR number, or job name so the alert tells you who to ask.

How can I customize it?

Change how often it runs (every hour, every 15 minutes, only during business hours, weekdays only).
Adjust what counts as stuck: the age threshold, the CPU floor, and how long a sandbox can be idle before it gets auto-killed.
Send the report to a different channel, or stay quiet on hours where there are no suspects to flag.

Frequently asked questions

Will this kill a sandbox that is actually doing real work?

No. The agent only auto-kills sandboxes that have been alive for at least an hour with near-zero CPU and no recent lifecycle activity. Anything busy or short-lived is just listed in the report so you can decide.

What happens on hours when nothing is stuck?

You can configure it to either send a short all-clear message so you know it ran, or stay quiet until there is actually something to flag.

Does it look at paused sandboxes too?

No. Paused sandboxes do not burn compute, so the workflow only inspects sandboxes that are currently running.

How does the agent figure out who owns each sandbox?

It reads the metadata tags you attach when creating a sandbox, like userId, PR number, or job name, and surfaces them in the alert so you know who to ping.

Does this work on the E2B Hobby plan?

Yes. Hobby sandboxes max out at one hour anyway, so the auto-kill mostly catches Pro plan sandboxes that have wandered past their useful life. The hourly triage report still works either way.