# Logs

Read what your build and your running application print: follow it live, narrow it to one request, or keep only the errors.

nesly keeps two kinds of output for each deployment: the **build** — what the build printed while it produced your image or files — and the **runtime** — everything your application writes to standard output and standard error, from every instance. Write to stdout and stderr; there is no log file to configure.

## From the CLI

```
nesly logs                          # the live deployment
nesly logs dep_3k2m…                 # one deployment, build included
nesly logs --follow                 # keep streaming new lines
nesly logs --worker mailer          # a background process, by its Procfile name
nesly logs --request 7f3c…          # only lines mentioning one request
nesly logs --json                   # one JSON object per line
```

Every response nesly serves carries an `X-Nesly-Request-Id`header. When a visitor reports an error, that id is the fastest way to the lines your application printed for that request — if your application logs it, or the error mentions it.

## In the console

The project's **Observability** tab shows the same output, following new lines as they arrive:

-   **Deployment** — whose output to read; the live one by default.
-   **Search** — only lines containing the text, a request id for example.
-   **Error lines** — only lines that report a failure: those mentioning error, fatal, panic, exception, traceback or a 5xx status.

A deployment that failed offers **Open logs**, which opens its output.

## Keeping logs elsewhere

To search months of output, alert on it, or keep it beside the rest of your systems, send it continuously to your own log platform with a [log drain](/docs/log-drains/).

---
Canonical: https://nesly.net/docs/logs/
Markdown: Accept: text/markdown on the HTML URL, or replace the trailing slash with .md