# Logs

Every log a Buddy Sandbox produces - setup, fetch, apps, commands, HTTP requests, and the activity audit trail - and where to read each in the UI and the CLI.

Each part of a Sandbox keeps its own log.

| Log | What it contains |
| :--- | :--- |
| **Setup** | First boot commands and fetch steps, with exit codes |
| **App** | Output of a long-running application |
| **Command** | Output of a single executed command |
| **HTTP requests** | Requests arriving on an endpoint |
| **Activity** | Who did what to the Sandbox |

## Setup log

Everything that happened while the Sandbox was being provisioned: stdout and stderr of the [first boot commands](/docs/sandboxes/configuration.md), and of each [fetch](/docs/sandboxes/git-and-artifacts.md) source including its build command, with exit codes.

In the **Logs** tab, pick the **Boot** entry - labeled **First Boot CMDs** - from the dropdown. Search and refresh help you find a specific line.

![Sandbox logs](/docs/sandboxes/sandboxes-logs.png.md)

From the CLI:

```bash
bdy sb logs my-sandbox
```

A Sandbox that comes up with no application running usually shows the reason here: a failed apt-get, a build command that exited non-zero, or a repository that was never cloned. It does not contain application output — that has its own log.

## App logs

Each [app](/docs/sandboxes/apps.md) has a separate stream. The same **Logs** tab dropdown switches between apps and the **Boot** entry.

![Log source dropdown](/docs/sandboxes/sandboxes-logs-dropdown.png.md)

From the CLI:

```bash
bdy sb app logs my-sandbox <app>
```

## Command logs

Every [executed command](/docs/sandboxes/running-commands.md) is recorded with its status, exit code, the runtime it ran in, and full output. The same **Logs** tab lists them under an `Exec` entry in the dropdown, so you can look back at what was run and what it printed.

![Command history](/docs/sandboxes/sandboxes-command-history.png.md)

From the CLI, list them and read any one:

```bash
bdy sb exec list my-sandbox
bdy sb exec logs my-sandbox <command-id>
```

Output can also be streamed live while the command is still running - see [Running commands](/docs/sandboxes/running-commands.md).

## HTTP request logs

[HTTP endpoints](/docs/sandboxes/endpoints.md) can log incoming requests. Open the endpoint from the **Tunnels** section and flip the **Request logging** flag in its settings. A **Requests** tab shows up on the endpoint view, and that is where you read the log.

Request logging shows whether traffic is reaching the Sandbox at all. Requests appearing in the list mean the endpoint is fine and the problem sits in the application; an empty list points to the endpoint itself.

![The Requests tab of an endpoint with request logging enabled](/docs/sandboxes/endpoints-requests.png.md)

## Activity

The **Activity** tab is the audit trail: it records lifecycle operations - who started, stopped, or deleted the Sandbox, and what was executed in it. Use it to answer "who changed this machine and when". Access rules themselves are covered in [Permissions and security](/docs/sandboxes/permissions-and-security.md).

![Sandbox activity](/docs/sandboxes/sandboxes-activity.png.md)

## Which log do I open?

| Symptom | Start here |
| :--- | :--- |
| Sandbox is up, app is missing | Setup log |
| App crashes or restarts | App log |
| A script did not do what you expected | Command log |
| The URL returns an error | Request logging on the endpoint, then the app log |
| Something changed and nobody knows who | The **Activity** tab |

More symptoms and fixes in [Troubleshooting](/docs/sandboxes/troubleshooting.md).

<Hint type="info">

Logs can also be read programmatically - over the [REST API](/docs/api/sandboxes/get-app-logs.md), from the [SDK](/docs/sandboxes/sdk.md), and through [MCP](/docs/ai-agents/mcp.md) by AI agents.

</Hint>


---
Original source: https://buddy.works/docs/sandboxes/logs