Keep it running
When a build fails — and what the log is telling you
A failed deploy hands back a reason, not a wall of output. Four failures cover most of them, and one of the four prints nothing at all — which is exactly when a log tail would tell you least.
Where to look
A failed release carries its reason there. Your agent reads the same thing, which is why "it failed, fix it" is usually enough to say.
1. It ran out of memory
The one that looks like nothing happened. The build is killed by the kernel before it can write anything, so the last thirty lines of the log are empty exactly when you need them most. Erawan reports the exit code instead — 137 — and says so in words, because "the log is empty" and "the build was killed" are the same picture and opposite problems.
Usually a bundler on a large project. Cut what the build loads, or move up a plan.
2. A file the Dockerfile copies is not there
This one hides. BuildKit reports it as failed to compute cache key, with two opaque reference ids before the filename, which reads like a fault of ours. The filename is lifted out and put first — almost always a path in a COPY that is spelled differently from the file, or one excluded by .dockerignore.
3. A dependency will not install
A version that does not exist, a package renamed, a lockfile from a different platform. The failing line is quoted with the tail after it. This is the one worth handing straight back to your agent: it wrote the dependency list and it can read the error.
4. The build produced no files
Only for a site rather than a service. npm run build exited happily and wrote nothing where we look — dist, build, out, public, .output/public. Usually a build configured to output somewhere else.
Why you get one message and not the whole log
BuildKit prints the same failure twice — once as the step that failed and again as the solve error underneath it. Handed back raw, that reads as two problems and sends whoever is fixing it hunting for a second cause. Saying it once, with the tail after it, is the difference.
The version that is running is untouched
A failed build changes nothing. The release that was live stays live and serves every request while you fix it — a deploy that fails costs you the wait and nothing else.