E2B sandbox crash to Linear bug automation

Build me a webhook-triggered agent workflow that turns unexpected E2B sandbox deaths into Linear bug tickets in real time, with a short Slack heads up so on-call engineers actually see them.

Trigger: an incoming webhook from E2B for sandbox.lifecycle.killed events. E2B supports outgoing webhooks for sandbox lifecycle events signed with a shared HMAC secret, so during setup I want to register the webhook against my E2B team and have the workflow verify the signature on every incoming request before doing any work.

When a kill event arrives, do this:

1. Use Get Sandbox Lifecycle Events to pull the timeline for that sandbox, and Get Sandbox Logs to pull the tail of console output. If useful, call Get Sandbox to grab metadata like the template id, alias, started-at, and any owning agent name stored in the sandbox metadata.

2. Decide whether the kill looks intentional or like a real crash. Intentional: a clean user-initiated kill, an expected TTL expiry, or a normal shutdown at the end of a task. Crash: non-zero exit code, OOM signal, abrupt termination mid-task, or any abnormal lifecycle reason. Silently drop the intentional kills, do not file anything, do not Slack anything.

3. For crashes, dedupe first. Use Linear Search Issues (or List Issues with a filter) to look for an open issue labelled sandbox-crash whose title matches the same template id, created inside the last hour. If one exists, add a Linear comment on that issue summarising this new occurrence (sandbox id, time, one-line reason from the lifecycle event) and exit without filing a new ticket and without sending a new Slack ping.

4. If there is no recent duplicate, use Linear Create Issue in the designated engineering team. Title: 'E2B sandbox crash on {template_id}'. Description in Markdown should include: sandbox id, template id and alias, owning agent name, runtime so far, the abnormal lifecycle event (with reason and exit code if present), and the last ~50 lines of console output in a fenced code block. Apply the 'sandbox-crash' label and set a sensible default priority.

5. Use Slack Bot Send a Message to post a short alert in the on-call channel: one line with the template id and reason, plus a link to the new Linear issue. Keep it tight, this is a triage ping, not a report.

Configurable knobs I want exposed at setup: which Linear team, label, and default priority the bug lands on, which Slack channel gets the alert (with optional per-template routing), the dedupe window (default 1 hour), and the exact patterns that count as 'crash' versus 'intentional' so we can tune false positives without editing the workflow.

Keep the agent strictly reactive: one incoming kill event in, at most one Linear write and one Slack write out. Never create executions for sandboxes the agent did not start, and never act on lifecycle events other than killed.

Additional information

What does this prompt do?

Listens for sandbox kill events from E2B in real time so crashes never sit in a dashboard nobody checks.
Reads the lifecycle timeline and the tail of console output to tell intentional kills apart from real crashes.
Files a Linear bug in your engineering team with the template, the failing event, and the relevant log excerpt, and tags it with a sandbox-crash label.
Posts a short Slack alert in your on-call channel with a link to the new Linear issue so the right person sees it immediately.
Skips duplicate filings when the same template crashes repeatedly inside a short window, so a flapping sandbox does not spam your backlog.

What do I need to use this?

An E2B account with permission to register an outgoing webhook for your team.
A Linear workspace and the team you want crash bugs filed in.
A Slack workspace and a channel for on-call alerts.

How can I customize it?

Pick which Linear team, project, and label the crash bug lands in, and set a default priority.
Choose the Slack channel for alerts, or route different sandbox templates to different channels or owners.
Tighten or loosen the rules for what counts as a crash, and change the dedupe window so a noisy template does not spam your backlog.

Frequently asked questions

What counts as a crash versus a normal shutdown?

The agent treats non-zero exits, out-of-memory kills, and abrupt mid-task terminations as crashes. Clean user-initiated kills and expected timeouts are ignored, so you only get tickets for things engineers actually need to fix.

Will I get a flood of Linear issues if one template keeps crashing?

No. If an open sandbox-crash issue already exists for the same template inside the dedupe window, the agent adds a short comment to that issue instead of opening a new one.

Does this work with sandboxes started by any agent or SDK?

Yes. As long as the sandbox runs in your E2B team, the kill event reaches the workflow regardless of which agent framework or SDK started it.

Can alerts go to more than one Slack channel?

Yes. You can route by template name, environment, or owning team in the prompt, so platform crashes ping the platform channel and product crashes ping the product channel.

Can I require more than one crash before a bug is filed?

Yes. Tell the agent to wait for a threshold, for example two crashes on the same template within ten minutes, before opening a Linear issue. Single crashes can fall through to a Slack heads up only.