Monitor E2B sandboxes with Sazabi

Last verified on Nov 8, 2026.

When an AI agent writes code and runs it, the interesting output is what the code printed. A traceback, a failed install, a script that wrote nothing at all. An E2B sandbox is short-lived, so that output vanishes with it unless your host process catches it.

Sazabi, the AI-native observability and security platform, takes the output as log records. The host application forwards each line over OTLP. Nothing is installed in the sandbox, which is why this works with any code the sandbox runs.

What Sazabi reads from E2B

There is one method, and the data goes one way: from your host to Sazabi. The host is the process that creates sandboxes through the E2B SDK. It adds an OpenTelemetry log exporter and routes the SDK's output callbacks through a log emitter. The exporter posts to your intake URL with /v1/logs appended.

The Sazabi docs for this source use @e2b/code-interpreter in TypeScript and e2b_code_interpreter in Python. Each stdout or stderr line becomes one record. The record body is the line. Attributes stream and sandboxId say which stream it came from and which sandbox ran the code, and stderr lines get severity ERROR. The example ends by killing the sandbox and shutting down the logger provider so buffered lines are sent.

E2B's own docs explain where the lines come from. runCode() accepts onStdout, onStderr and onError callbacks. Each output message is an object with error, line and timestamp, and the timestamp is in microseconds. commands.run() takes onStdout and onStderr as well, which covers shell commands outside the code interpreter. E2B notes that a stream stays open for more than an hour with keepalive pings every 50 seconds, but no connection is guaranteed that long, so a long job needs a client that can reconnect.

Only what you route through the callbacks reaches Sazabi. If you want onError events, add that callback to the emitter too.

Questions it answers

• What did a given sandbox print to stderr before it was killed?
• Which sandboxes produced any ERROR lines in the last hour?
• Did the generated code install its packages, or did pip fail?
• How many lines does a typical execution write?
• Which runs wrote nothing, so the agent saw an empty result?
• What was the host application logging while that sandbox ran?

A worked example: generated code that fails quietly

An agent generates a data-cleaning script and reports success. The user says the file is empty. The host process forwarded every line, so you can look at one record from that sandbox. Here it is, with invented values and the fields from the Sazabi page.

{
  "body": "ModuleNotFoundError: No module named 'pandas'",
  "severityText": "ERROR",
  "attributes": {
    "stream": "stderr",
    "sandboxId": "sbx-7f3a91"
  }
}

Find it from the terminal:

sazabi logs ask "show all lines from sandboxId sbx-7f3a91 in order, and say whether stderr came before any stdout"

The first line is the cause: the sandbox image lacked the package, the script died on import and nothing downstream ran. The agent still replied with a polite summary, because it never read stderr. Two fixes follow. Bake the dependency into the sandbox image. Then feed stderr back to the agent so it can see its own failures. Without these records you would have a blank file and no trail.

Why the host is the right place

Sandboxes are cheap to create and discard, so per-sandbox logging agents are impractical. The host already knows the sandbox ID, the user and the task. Add those to the emitter's attributes and the same filter that finds a sandbox also finds the request behind it.

How it fits with other integrations

E2B has company in the sandbox space. Daytona streams logs and traces for every sandbox from one organization setting, and Trigger.dev covers the task runs that often start these sandboxes, and sits in the durable execution category. The integrations index lists the rest. The shared transport is explained on the OpenTelemetry integration page, and pricing explains how line volume counts.