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.