Skip to main content
Everything your application writes to stdout and stderr is captured while it runs. No agent, sidecar or SDK is involved; it is collected by the platform underneath, and the dashboard reads it back.

​
Reading them

Open the Logs tab inside your app and click Show logs. Logs are behind a click rather than loaded with the page on purpose: reading them is a billed query against the logging backend, and most visits to an application page are not debugging. Once loaded, tick auto-refresh to re-read every ten seconds. Untick it to stop. That is the whole control surface.

​
What you see

  • Your application’s own output, verbatim, oldest line first.
  • Failed requests: the platform’s own record of any request that returned 4xx or 5xx, which catches errors your app never logged itself.
Successful requests are filtered out. Most frameworks print their own access line for every request, so including the platform’s record too would show everything twice.
Colour codes are stripped. Frameworks emit ANSI escapes that survive into the log store, and Flask’s banner would otherwise arrive as [33mPress CTRL+C to quit[0m.

​
Scope and retention

There is no log search, no level filter, no time-range picker, and no export. You get the most recent lines and your browser’s find-in-page.If you need to search across a longer history, log in a structured format and ship it to a service you control.

​
If logs will not load

Reading runtime logs requires a permission on the underlying cloud project that is not granted by default. If it is missing, the Logs tab says so and names the role to grant rather than showing an empty panel. Build logs are separate: they are written to Antideploy’s own storage and appear against the deployment, including when a build fails.

Deployments

Release history, build logs, and rolling back.