# Logs and deployments

Once your app is running, two things you'll reach for constantly:

- **Application logs** — what your running app is printing (requests, errors, debug messages).
- **Deployment history** — a list of every version you've pushed, with build logs for each one.

This page covers both.

## Application logs

Print the most recent log lines from your running app:

```sh
dina apps logs --app my-app
```

By default you get the last 100 lines. Ask for more or fewer with `--lines` (`-n` for short):

```sh
dina apps logs --app my-app --lines 500
dina apps logs -a my-app -n 20
```

Logs are whatever your app writes to stdout and stderr. If your framework buffers output aggressively, you might not see messages until the buffer flushes — flush on exit or disable buffering for debugging.

## Deployment history

Each time you run `dina deploy`, Dina records a **deployment** — even the failed ones. To list them:

```sh
dina apps deployments --app my-app
```

You'll see a table with each deployment's ID, status, source type (was it an image or a source upload?), creation time, port, and replica count.

For a machine-readable version:

```sh
dina apps deployments --app my-app --output json
```

### Deployment statuses

The most common statuses you'll see:

- **`pending`** — queued, hasn't started yet.
- **`building`** — image is being built from your source.
- **`deploying`** — build finished, rolling out to the platform.
- **`running`** — live.
- **`failed`**, **`build_failed`**, **`deploy_failed`** — something went wrong. See the build logs.

## Build logs for a specific deployment

When a deployment fails, the build logs tell you why. First, find the deployment's ID (the first column of `dina apps deployments`), then:

```sh
dina apps deployments logs --app my-app --id <deployment-id>
```

You'll see the full build output — everything your Dockerfile printed, plus platform-level messages about the rollout.

<div class="callout"><strong>Tip:</strong> <code>dina apps info --app my-app</code> shows the ID of the currently active deployment. That's usually the one you want to inspect.</div>

## Piecing it together

A typical debugging session after a failed deploy:

```sh
# Did it fail?
dina apps deployments --app my-app

# Why?
dina apps deployments logs --app my-app --id <id-from-above>

# Fix the code, then redeploy and watch it finish:
dina deploy --app my-app --wait
```

If the deploy succeeds but the app misbehaves in production, flip to the application logs:

```sh
dina apps logs --app my-app --lines 500
```

## Scripting and piping

The raw log output is plain text, so you can pipe it straight through `grep`:

```sh
dina apps logs --app my-app --lines 1000 | grep ERROR
```

For programmatic use, `dina apps deployments --output json` is stable enough to script against.