Debug a customer's E2B sandbox from their support ticket

Build me an internal support console my support engineers open whenever a customer writes in saying "the code execution broke". The people using it have no E2B login and should not have to ask an engineer for help. They arrive holding a Zendesk ticket and a customer name, never a sandbox id like iog8cj8k9sggm1rtci24w, so the entire job of this app is to bridge from the customer to their sandboxes and then explain in plain language what actually happened.

Start with a ticket lookup page. The engineer types a ticket number, a customer email or a few words from the complaint, and the app uses Zendesk Search Tickets to show matching tickets with subject, requester, organization, status and when the ticket was created. Selecting one opens the ticket view, which uses Zendesk List Ticket Comments to show the conversation so the engineer can read the customer's own description and pin down the window when things went wrong. Keep the ticket id, requester email and organization in view from here on, because those are the values the sandbox search runs on.

From the ticket, the engineer moves to the sandbox search. This is the heart of the app. We tag every sandbox we start with a customer or user identifier in its metadata, so the app should call E2B List Sandboxes with a metadata filter on that identifier rather than asking for a sandbox id. Prefill the search box with the requester email and the organization name pulled off the ticket, and let the engineer edit it or try a different identifier. Show the results as a table of that customer's sandboxes with sandbox id, state (running or paused), template, started at, and how long each one ran, sorted newest first. Since the engineer is trying to match the complaint window, let them narrow the list to sandboxes that started within a time range around the ticket, and visually mark the ones that overlap the window the customer described.

Picking a sandbox opens the detail page. It should pull four things together: E2B Get Sandbox for the allocation and template (vCPU, memory limit, disk, template id, state, timeout setting, start time), E2B Get Sandbox Lifecycle Events for the timeline, E2B Get Sandbox Metrics for CPU, memory and disk usage over time, and E2B Get Sandbox Logs for console output. Render the lifecycle events as a readable vertical timeline using the real event types (sandbox.lifecycle.created, updated, killed, paused and resumed) translated into plain phrases like "session started", "settings changed", "paused", "resumed" and "terminated", each with its timestamp and the gap since the previous event. Render the metrics as three small time series charts for CPU, memory and disk, drawing the memory limit from Get Sandbox as a horizontal ceiling line so it is obvious when a session ran up against it.

Every sandbox detail page has an Investigate button that kicks off a background agent. The agent reads the logs, the metrics and the lifecycle events together and decides which of four things happened: the session ran out of memory, it hit its configured timeout, it was killed early, or it crashed. Memory pressure shows up as usage climbing toward the limit from Get Sandbox before the session ends. A timeout looks like a run whose duration lands at the configured timeout with no kill event preceding it. Killed early means a sandbox.lifecycle.killed event arrived well before the timeout would have fired. A crash shows up in the console output with the process dying while resources were still healthy. The agent writes a root cause brief in plain language back into the app and attaches it to that sandbox so anyone opening the page later sees the previous finding instead of re-running the work.

The same agent then does two more things. Before filing anything, it checks Linear with Search Issues for an existing matching bug, searching on the failure signature and the template rather than the customer name so it finds bugs filed from other customers hitting the same problem. If it finds a match, it links the existing issue in the brief and files nothing. Only when there is no match does it call Linear Create Issue with the root cause, the sandbox id, the template, the timeline and the relevant log excerpt. Either way it posts the finding to Zendesk with Update Ticket as an internal note, not a public reply, so the agent who is replying to the customer has the answer in front of them without the engineer having to relay it.

Some rules I want baked in. A support engineer should never see a raw stack trace as the headline: the plain language brief goes first, and the raw console output sits behind a "Show raw logs" toggle further down the page. The Linear dedupe check always happens before anything is filed, and the app should show which existing issue it matched so the engineer can see the decision rather than trust it blindly. Sandboxes are only retained for a limited window, so when the metadata search comes back empty the app must say plainly "No sandbox found for this customer in the retained window" along with what identifier it searched on and a suggestion to try the organization name or a different tag, rather than showing an empty table that looks like a broken page.

A few data details to handle correctly. Sandbox metrics are collected roughly every five seconds and can be empty for the first second of a sandbox's life, so a short session may legitimately have few or no data points: say so on the chart instead of rendering an empty box. Get Sandbox Logs uses offset pagination with a maximum limit of 1000 and a 0-based start, so page through it and let the engineer load more rather than truncating silently. Lifecycle events use offset pagination with a limit between 1 and 100 plus an offset and an ascending order flag, so fetch them oldest first for the timeline. Sandbox ids stay the same across pause and resume, so a session that was paused and resumed is one row, not two.

One hard constraint: this app reads and diagnoses, it never reproduces a bug by running code. The E2B REST API covers sandbox lifecycle and observability only, and executing anything inside a sandbox needs the E2B SDK over an internal protocol, so do not build any "re-run this" or "open a shell" action anywhere in the app.

Persist investigations in the app so they survive a reload: store the brief, the classification, the matched or created Linear issue, whether the Zendesk note was posted, who ran the investigation and when, keyed by sandbox id. Show a small history on the ticket view listing every sandbox investigated for that ticket, so a second engineer picking up the ticket sees the work already done.