Monitor Daytona sandboxes with Sazabi

Last verified on Nov 8, 2026.

A sandbox is where an agent's code actually runs: installs, builds, test runs, a dev server. Daytona records what happens inside, and it keeps that record for three days. A failure someone reports on Monday may already be gone by Thursday.

Sazabi, the AI-native observability and security platform, takes the same stream as a manual log source. It holds the logs and traces longer than Daytona does and puts them next to the rest of your services. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.

What Sazabi reads from Daytona

One method, one direction. In Daytona you set an OTLP endpoint at the organization level, and every sandbox pushes its logs and traces to your Sazabi intake URL. Sazabi does not call back into Daytona.

The Sazabi docs for this source say there is no per-sandbox configuration. Sandboxes begin exporting on their next start. Records carry resource attributes such as daytona_organization_id, daytona_region_id and daytona_snapshot. The Sazabi page notes that Daytona metrics are not stored; only logs and traces are.

Daytona's own page fills in what is in those two signals. Logs are application output from stdout and stderr, system logs, and runtime errors and warnings. Traces are HTTP requests and responses plus custom spans from your application code. Every record is labeled with service.name, service.instance.id (the sandbox ID), the organization, the region and the snapshot used to create the sandbox.

Two Daytona settings change how the data reads. By default service.name is sandbox-<id>, so a fleet looks like one service per sandbox. Set DAYTONA_SANDBOX_OTEL_SERVICE_NAME when you create a sandbox and they share one name, with service.instance.id still identifying each. Set DAYTONA_SANDBOX_OTEL_EXTRA_LABELS to a list such as team=backend,env=staging and those pairs are added as resource attributes. Both are read once at startup.

Only organization owners see the OpenTelemetry card, so ownership decides who can connect this.

Questions it answers

• What did a sandbox print before it stopped responding?
• Which daytona_snapshot has the most failing sandboxes?
• Did a sandbox in one daytona_region_id behave differently from the others?
• Which HTTP calls inside a sandbox returned errors last week?
• Which sandbox does service.instance.id point to, for this trace?
• What did a sandbox do on a day Daytona has already dropped?

A worked example: one bad snapshot

An agent platform builds sandboxes from a few snapshots. After you publish a new one, setup commands start failing in some sandboxes. Daytona's three-day window is enough to see today's failures, but not to compare them with last week's. Sazabi holds both. The attribute that makes the comparison possible is daytona_snapshot.

resource: daytona_snapshot=py-agent-v7  daytona_region_id=us  service.instance.id=sbx-3c91
body:     pip install: error: externally-managed-environment
severity: ERROR

This record is invented, and its field names come from the two pages above. Ask the Sazabi agent in a thread:

Group ERROR logs from Daytona sandboxes by daytona_snapshot for the last 14 days.
Which snapshot started failing, and on what date did it first appear?

If py-agent-v7 appears with the failure for the first time on the day you published it, the snapshot is the cause, not the user code. The fix belongs in the snapshot build, not in each agent prompt. If several snapshots fail the same way, look at daytona_region_id instead. A single region failing points at the environment around the sandbox.

Mind the grouping

If you leave the default service.name, expect one service per sandbox in any view that groups by service. Filter on daytona_organization_id or daytona_snapshot instead, or set the shared service name before sandboxes start.

How it fits with other integrations

Daytona sits beside E2B, where the host application forwards sandbox output rather than the platform doing it. If a Trigger.dev task or a coding agent such as Claude Code starts your sandboxes, their logs can sit in the same Sazabi project. The wire format is covered on the OpenTelemetry integration page, and pricing explains how volume is counted.