Logs
Sandbox console logs and entrypoint logs.
When a sandbox misbehaves, logs are the first place to look. Daytona keeps two separate log streams per sandbox, because they answer different questions: the console log is the machine's serial output — what you'd see on a monitor plugged into the VM — while the entrypoint log is the stdout/stderr of your image's entrypoint process. Both are available live while the sandbox runs and are preserved after it stops or fails, so you can debug a sandbox that's already gone.
Console logs
GET /vms/:id/logs returns the sandbox's console/serial output as plain text. This is where boot-time problems show up: an image whose entrypoint never starts, kernel messages, out-of-memory kills, and crash output that never made it into any application log. If a sandbox ends up in an error state, read this first.
For a running sandbox the log is fetched live; for a stopped or failed sandbox you get the persisted copy captured at shutdown.
Entrypoint logs
GET /vms/:id/entrypoint-logs returns the stdout and stderr of the image's entrypoint — your application's own output. If the sandbox booted fine but your service inside it is failing, this is the stream you want.
Like console logs, entrypoint logs are read live from a running sandbox and served from the persisted copy after it stops or fails.
Which log answers which question?
| Symptom | Look at |
|---|---|
Sandbox stuck creating / went to error | Console log |
| Kernel messages, OOM kills, crashes | Console log |
| Entrypoint started but the app misbehaves | Entrypoint log |
| Service prints to stdout/stderr | Entrypoint log |
| Output of commands you ran via the SDK | Returned by the call itself — see Running Commands |
| Image failed to build | Build logs (below) |
Note: commands executed through
sandbox.processreturn their output directly and are not written to either log stream. For long-running session commands, useget_session_command_logs/getSessionCommandLogs.
Dashboard
The Logs tab on a sandbox's page in the dashboard shows both streams without any curl-ing — usually the fastest path when debugging interactively.
Build logs
Logs from building images and snapshots belong to those resources, not to any sandbox — a build failure happens before a sandbox ever exists. See Images and Concepts → Snapshots for how to inspect build status and errors.
See also
- Usage Metrics — when the question is "what is it doing" rather than "what did it say".
- Running Commands — capturing output of your own commands.