Logs

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-Idheader. 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.