Build logs are the single most useful debugging artifact you have when a deploy goes sideways. A red "build failed" badge tells you nothing; the 200 lines above it tell you everything. This tutorial covers how to read, stream, and search live build logs effectively — and the recurring failure patterns you can catch from them.
Why live logs matter
A container build is a pipeline: clone the repo, resolve dependencies, compile or bundle, produce an image, push it to a registry, then deploy. A failure anywhere in that chain surfaces as a non-zero exit code, but the *reason* is buried in stdout/stderr from the tool that failed — your package manager, your compiler, BuildKit itself.
"Live" matters because a 6-minute build that hangs at minute 4 shouldn't make you wait until it times out. Streaming logs let you spot a stuck npm install resolving peer dependencies, or a Docker layer download stalling, in real time.
Viewing live logs on PandaStack
When you push to a connected Git repo, PandaStack runs the build in an ephemeral Kubernetes Job pod and tails its output straight to the dashboard. Open your service, go to the Deployments tab, and select the in-progress deploy. Logs stream line-by-line as the build pod writes them — there's no "refresh to see new output" step. Under the hood, log lines are shipped to a self-hosted Elasticsearch cluster, which is what makes historical search possible after the build finishes.
There are two distinct log streams, and confusing them wastes time:
- Build logs — output from the build pod (dependency install, compile, image push). Look here for build failures.
- App (runtime) logs — stdout/stderr from your running container. Look here for crashes *after* a successful deploy.
If your deploy shows "build succeeded" but the service is unhealthy, you want runtime logs, not build logs.
A reading strategy that works
Don't read top-to-bottom. Read bottom-up:
- 1Start at the last line. The final error and exit code are almost always at the very bottom.
- 2Scroll up to the first
ERROR/error/npm ERR!. The first error usually causes the cascade of later ones. - 3Find the stage boundary. Identify which pipeline stage failed — install, build, or push. That narrows the cause dramatically.
Searching logs
Once a build completes, the full log is searchable. The highest-value searches:
error
ERR!
failed
not found
exit code
ENOENT
killedkilled and exit code 137 are special: 137 means the process was OOM-killed (out of memory). That's not a code bug — it's a resource limit. See the table below.
| Symptom in logs | Likely cause | Fix |
|---|---|---|
exit code 137 / Killed | Build OOM | Raise build memory tier, or reduce parallelism |
ENOENT: no such file | Missing file / wrong path | Check build context and .dockerignore |
npm ERR! peer dep | Dependency conflict | Pin versions, use a lockfile |
manifest unknown | Bad base image tag | Fix FROM tag in Dockerfile |
Hang at RUN npm install | Network or resolution stall | Add lockfile; cache dependencies |
permission denied | Rootless build expecting root | Avoid root-only steps; use rootless-safe images |
Reproducing a build locally
Logs tell you *what* failed; reproducing tells you *why*. If your build uses a Dockerfile, you can replicate the same steps locally with BuildKit:
# Enable BuildKit and build with full plain output
DOCKER_BUILDKIT=1 docker build --progress=plain -t myapp:debug .--progress=plain disables the collapsing TUI and prints every line — exactly what you want when comparing against your platform's logs. For auto-detected (buildpack) builds, reproduce by running the detected install/build commands directly in a clean checkout.
Common gotchas
- Logs truncated mid-build? The pod likely crashed (often OOM). Search for
137. - No logs at all? The build pod may have failed to schedule — usually a quota or image-pull issue, shown as a separate scheduling event rather than build output.
- Secrets in logs. Never
echo $SOME_TOKENin a build step. Build logs are persisted and searchable; treat them as semi-public within your org. - ANSI color noise. Some tools emit escape codes. Search by the plain substring (
error) rather than expecting clean formatting.
Make future builds easier to debug
- Commit a lockfile (
package-lock.json,yarn.lock,pnpm-lock.yaml,go.sum). Deterministic installs produce deterministic logs. - Keep build steps small. One concern per
RUNso the failing step is obvious. - Echo a marker between phases (
echo "=== running tests ===") so you can grep to the right section instantly. - Fail fast. Use
set -euo pipefailin shell build scripts so the first error stops the build instead of producing confusing downstream noise.
References
- [Docker build output and
--progress](https://docs.docker.com/reference/cli/docker/buildx/build/) - [BuildKit documentation](https://github.com/moby/buildkit)
- [Kubernetes Job logs (
kubectl logs)](https://kubernetes.io/docs/concepts/workloads/controllers/job/) - [Elasticsearch full-text search](https://www.elastic.co/guide/en/elasticsearch/reference/current/full-text-queries.html)
- [npm error codes](https://docs.npmjs.com/common-errors)
---
Live, searchable build logs come standard on PandaStack — including the free tier, which gives you 300 build minutes a month. Connect a repo and watch your first build stream in real time at [dashboard.pandastack.io](https://dashboard.pandastack.io).