Skip to content
Deployments

Logs

Build logs and runtime logs, where each lives, how to filter them, and what Kuppit does to them before you see them.

Logs belong to a deployment. A build writes the Build log; the revision it started writes the Runtime log. Both are on the deployment's page, and the service's Logs tab shows the runtime log of the deployment currently serving traffic, which is the one that matters when something is wrong in production.

Kuppit reads logs live from the infrastructure. It stores no copy, so what you see is what the platform holds, back to when the deployment was created and for 30 days at most.

Build and Runtime

The viewer switches between the two streams.

Build is the output of turning the commit into an image: dependency installation, your build command, the Dockerfile's steps. Registry transfers, layer progress and the builder's own step markers are hidden behind Show infrastructure logs, because they are rarely the line you are looking for.

Runtime is what the revision writes once it starts. It is split by source:

SourceTagWhat it is
AppAPPYour application's stdout and stderr.
RequestsHTTPOne line per request the revision served. Off by default, because a single page load can be dozens of asset requests.
SystemSYSTEMThe platform's own messages about the revision: starting, stopping, failing a health check.

A severity filter narrows either stream from All severities to Critical only. When a deployment fails, the page opens the stream that failed with errors already selected.

Following a live deployment

Runtime logs tail while a deployment is in progress and while a service is serving, refreshing every few seconds. Pause holds the view where it is; Resume catches up. A tab left in the background stops polling until you return to it.

Under heavy output the viewer says High log volume and hides some entries rather than falling behind. Narrow the filters, or pause and read.

Before you see a line

Kuppit redacts the service's secret values from every line before returning it, so a secret printed by accident does not become a secret in your logs. Only the values are redacted, not the names.

What is not here

  • A project has no Logs tab. Logs come from a deployment, and a project has many; the service's Logs tab answers "which deployment" by showing the one serving traffic.
  • A PostgreSQL resource has no logs. It has a status and a Connect tab.
  • There is no log export or search index. Read them here, or through the infrastructure's own tools where you have access.
Was this page helpful?