Key idea
Each log covers one stage. The build log covers turning code into an image, the deploy log covers starting it, and the runtime log is your app talking once it's running. When the deploy log names a failure, its label tells you which of the other two to open next.
Three logs, three stages
- Build log: only for services built from a repository. It shows fetching your code, installing dependencies and building the image. Reading build logs covers it.
- Deploy log: ComputeSphere's own record of each rollout: pulling the image, starting spherelets, health checks, and finally Live. Your app writes nothing here.
- Runtime log: everything your app prints, from every spherelet, for as long as it runs. "Prints" means writing to standard output or standard error, the two streams a terminal shows when you run the app locally.
In the console they're on the service's Logs tab (Runtime and Deploy) and its Builds tab. From the terminal, csph logs <service> shows runtime logs; add --kind deploy or --kind build for the others.
When the deploy log names a failure
Deploying, Running, Failed listed the usual causes. The deploy log names them with a label, and each label points somewhere:
| Label | What happened | Open next |
|---|---|---|
| Image pull failed | The image couldn't be downloaded | The image name, tag and registry credentials |
| Out of memory | The app used more memory than its shape has | The Metrics tab's Memory, then a bigger shape or a leak |
| Unhealthy | The app runs, but health checks are failing | The health check settings, and what the endpoint answers |
| Restarting repeatedly | The app keeps exiting as it starts | The runtime log: the last lines before each exit |
Each label comes with a short message, such as "The service is restarting repeatedly."
Reading them together
A crash on start leaves clues in two places. The deploy log says that it keeps restarting (Restarting repeatedly). The runtime log says why: usually the app's last line before exiting, such as a missing variable or a database it can't reach.
So the order is: deploy log first to learn which stage failed, then the log for that stage. An app that never started has nothing in its runtime log, and that tells you something too: look at the image or the port.
Check yourself