Logs
Build and runtime logs, where each one lives and how long it is kept.
Every app has two logs, and picking the right one is most of the work of reading them.
| What it holds | Read it when | |
|---|---|---|
| Build log | Everything from fetching your code to producing the finished image — dependency installs, compile output, the build command. | The deploy failed. Your app never started. |
| Runtime log | Everything your app has printed since it started, on its own output. | The app is up but behaving wrongly, crashing, or answering with an error. |
Both are on the app's Logs tab in the console, and the runtime log updates live while you watch it.
What ends up in the runtime log
Whatever your app writes to standard output or standard error. For most frameworks that is already the default — a print, a console.log, an exception traceback and the framework's own request lines all arrive without you configuring anything.
You do not need a logging service, a log driver, or an agent in your image. If your code prints it, we keep it.
Write logs to output, not to a file. An app that writes to app.log on disk is writing into a container that is replaced on every deploy, and nothing will read it. Printing is both simpler and the thing that works here.
How long they are kept
Seven days, then they age out.
That is deliberate rather than a limitation of the storage: logs are a debugging trail, not a system of record. If you need something for longer than a week — an audit trail, an event history, anything you would be asked to produce later — write it to your database, which is backed up. A log is the wrong place for it, on any platform.
The same seven days applies to what the console shows and to what is kept on disk, so there is no window where the console hides something that still exists.
What is not in the logs
- Anything from before the current retention window, as above.
- Our own platform's internals. You see your app, not the machinery around it.
- AI gateway calls in detail. A call your app makes shows up in the log only if your app prints it. What the call cost, which model answered and whether it failed is on the Usage tab instead, which is the better place to look for it.
Getting more out of them
Two habits make a runtime log worth reading, and both are in your code rather than in the console:
- Print something on startup — the app's version, and whether it found the settings it needed. A crash-on-boot is much easier to diagnose when the last line before it says which step it reached.
- Print the failure, not just that there was one.
except: passcosts you the only evidence you were going to get.
If you are looking at a failed deploy rather than a misbehaving app, start with When a deploy fails — it names what each build failure message means.