Build Failed With No Logs: How to Get Output

"Build failed." No stack trace, no compiler error, no output at all. A build failed with no logs is the least actionable message a platform can produce, and it usually means something specific that is worth understanding: the failure happened before the thing that produces logs started.

A build is not one step. It is four, and each fails differently.

The four stages

1. Fetching the source. The platform clones your repository at a ref. 2. Preparing the build. It works out how to build — Dockerfile, buildpack, or a detected framework. 3. Running the build. Your commands execute. This is the only stage that produces the output you are expecting. 4. Packaging. The result is turned into a runnable image.

If you have no logs at all, the failure was in stage 1 or 2. Your build never ran, so it could not have printed anything.

Stage 1: it never got your code

The symptoms are total silence and a fast failure — usually under fifteen seconds.

Common causes, in order:

• The branch does not exist. A service configured to deploy master against a repository that renamed to main. This fails instantly and says almost nothing.
• Access was revoked. The token or app installation that worked last month was removed, or the repository moved to an organisation where the grant no longer applies.
• The repository is private and the connection lapsed. Same shape as above; the platform gets a 404 rather than a 403, because that is what Git providers return for private repositories you cannot see.
• A submodule cannot be fetched. The main repository clones and a submodule using an SSH URL fails, because the build environment has no key for it.

The fast check: does the platform show a commit hash for the failed deployment? If it does not, it never got the code, and nothing in your Dockerfile is relevant.

Stage 2: it does not know how to build

Also silent, because no build command has been chosen yet.

• No Dockerfile where the config says. A dockerfilePath pointing at a path that moved.
• A monorepo without a root. The platform is looking at the repository root and your service is in apps/api.
• Detection found nothing. No recognised manifest, so no buildpack matched.
• A Dockerfile that fails to parse. A syntax error on line 1 fails before any layer runs.

Stage 3: this is where logs exist

If you are seeing partial output that stops abruptly, you are in stage 3, and the two most common causes are resources rather than code:

Out of memory. A build killed by the OOM reaper does not get to print anything about it. The log simply stops mid-step. TypeScript, webpack and Vite builds on large codebases hit this regularly, and the tell is that the same commit builds fine on your laptop, which has more memory than the builder.

Timeout. A build that exceeds the platform's limit is terminated. Same symptom: output that stops rather than ending.

Both look like "no logs" if the failure happens early enough.

Stage 4: it built but cannot be packaged

Rare and specific: the build succeeded and the artefact is wrong. An image with no CMD or ENTRYPOINT, an architecture mismatch, or an image too large for the platform's limit.

The diagnostic order

# Is there a commit hash? If not, stage 1.
dockup deployments my-project/my-api --json

# Build logs of the latest deployment, streamed as it goes
dockup logs my-project/my-api --build --follow

# The full record, including which stage took how long
dockup status my-project/my-api --json

stageTimings in that last output is the fastest way to locate the failure. A deployment that spent 0.4 seconds on clone and then ended failed at stage 1. One that spent ninety seconds building and then stopped is a stage 3 problem, most likely memory.

Getting output when there is none

Three techniques, in order of effort:

Reproduce the constraint locally. Not "does it build on my machine" — build it with the same memory the builder has:

docker build --memory=2g --memory-swap=2g -t test .

If that reproduces the failure, you have found it, and it is memory rather than anything mysterious.

Make your build louder. Most build tools are quiet by default about the thing that is about to kill them.

# Print progress so a truncated log still shows where it stopped
RUN npm ci --loglevel verbose
RUN NODE_OPTIONS="--max-old-space-size=3072" npm run build

That NODE_OPTIONS line is worth trying on its own — a Node build that dies silently is very often a heap limit, and raising it fixes builds that produced no diagnostic at all.

Bisect the Dockerfile. Comment out everything after the failing step and add RUN echo "reached step N" markers. Crude, and it works when nothing else does.

What reduces this class of problem

Two things matter more than any debugging technique.

Streaming logs rather than summarised ones. If output only appears after a build finishes, a build that is killed produces nothing, because the summary is written at the end. Streaming means the log you have when it dies is the log up to the moment it died.

dockup logs my-project/my-api --build --follow

Stages that are named and timed. "Build failed" is one bit of information. "Clone: 0.4s, build: failed after 94s" is enough to skip three of the four causes above without reading anything.

Frequently asked questions

Why does my build produce no logs at all? Because it failed before your build commands ran — usually fetching the source or working out how to build it. Neither stage produces build output.

Why does it build locally but not on the platform? Most often memory. Your machine has more of it than the builder. Reproduce with docker build --memory=2g to confirm before looking anywhere else.

What does a log that stops mid-step mean? The process was killed rather than exiting. Out-of-memory or a build timeout are the two candidates, and the OOM killer does not give the process a chance to explain itself.

Do I need a Dockerfile? Not necessarily — platforms can detect common project types and build without one. But detection failing is itself a silent, log-free failure, so an explicit Dockerfile removes a whole class of ambiguity.