View logs

Last updated

The Logs tab shows your process's stdout and stderr — live, or as a tail of recent output.

Live stream vs tail

  • Live streams new output as it happens. Use it while reproducing something.
  • Tail fetches a recent buffer. Use it after a restart, when the interesting part already happened.

Logs rotate — this matters

Container logs are capped at roughly 10 MB retained. For a quiet service that's plenty; for a chatty one it isn't.

The consequence to plan for: a fast crash loop scrolls its own cause out of retention. By the time you look, the original stack trace is gone and you're reading the hundredth identical failure.

So if something is restarting repeatedly, stop the app and read the logs from before it started looping, rather than letting it run while you investigate.

To keep the useful history:

  • One line per meaningful event, not per loop iteration.
  • Debug output behind a flag you turn on deliberately.
  • Truncate user-supplied text and don't log full request or response bodies by default.

If you see nothing at all

Almost always output buffering, not a platform problem. Many runtimes buffer stdout when it isn't attached to a terminal, so output sits in memory until the buffer fills — and is lost entirely if the process crashes first.

  • Python: set PYTHONUNBUFFERED=1 as an environment variable, or pass flush=True.
  • Others: look for the equivalent unbuffered or autoflush setting.

What to log so logs are useful

  • A startup line with your version and the configuration it loaded — variable names, never values. It distinguishes "never started" from "started and then failed", and it's the line most likely to survive rotation.
  • One line per unit of work, including the boring ones. "Checked 12 items, 0 new" is what tells you the app is alive.
  • An identifier — a request or job ID — on every line belonging to one operation, so you can follow it.
  • The remedy in fatal errors. BOT_TOKEN is not set beats a raw traceback.

Never log secrets. Anything in your logs can end up in a screenshot, a support thread, or an AI assistant's context.

Logs aren't the whole picture

The Events view shows platform actions and exit codes, which is where you confirm why something restarted — exit code 137 is out of memory, 1 is an unhandled error, 0 means your process finished normally (a bug, for a long-running app).

And remember that a running container isn't a working app: nothing checks whether your service actually responds.