Where logs live
Open Projects → Logs for the project log chooser, or open a project and select Logs. Build history is under Projects → Deployments and within each project.
The Logs tab on a project streams build output as it happens — dependency install, build steps, image creation, health checks — and once the deployment is live, the running app’s own output. It works the same way for a serverless agent: request-time logs show up here too, including cold-start wakes and tool calls, with no separate log destination to configure.
Reading a failed deploy
A build failure never replaces the running version — whatever was live before stays live. To find why, open the Logs tab for the failed run and read from the top: the pipeline runs in phases (source fetch, build, image push, rollout), and the log stream shows which phase was in progress when it stopped. A failure early — dependency install, a broken build script — points at your repository; a failure late — health checks never passing — usually points at something the app expects (an environment variable, a database connection) that isn’t set yet.
Automatically resumed deploys
If a deploy gets interrupted mid-run by something on the platform side rather than a failure in your code, it isn’t marked failed outright — the platform notices the run has gone quiet, picks it back up, and continues from the phase it reached rather than starting over. Phases already finished aren’t repeated, and you’re never billed twice for the same build.
First deploy: deploy an app from GitHub. Deploying an agent specifically: deploy a serverless agent. The story behind resumable deploys: Deploys that resume themselves.