MMcpeerigan

Note · 19 October 2026

It said success, and shipped nothing

A deployment reported complete, uploaded four fewer files than it was given, and said nothing about the difference. The missing part was the half that did the work.

A deployment we were running reported success every time. The pages it published were live and correct. The code behind them — the part handling sign-in and payments — was not running at all, and every one of its addresses returned a not-found.

The output said: uploaded 686 files, deployment complete.

We had given it 690.

The four missing files

The tool looks for that code in a particular place, relative to where it is run from rather than where the files are. We had put it somewhere that looked more logical — inside the folder being published.

So it did not find any, concluded there was none, and published a site that happened not to have any. Which is a perfectly reasonable thing to publish, and exactly what it reported doing.

It did not fail. It succeeded at a smaller job than the one we asked for.

The only evidence was a file count four lower than expected, in a line nobody reads, and the absence of two lines that appear when it does find the code.

Absence of error is not presence of outcome

This is the failure mode that survives longest, because every instinct says a green result means the thing happened:

  • An import that loads 900 of 1,000 rows and reports success, having skipped the ones it could not parse.
  • A backup job that completes in four minutes because it has been backing up an empty directory since a path changed.
  • A payroll run that processes everyone it could see, after a filter quietly excluded a department.
  • A mail merge that sends to the list it found, which is not the list you meant.

What to do

  • Count both ends. If you handed it 690, check it took 690. A tool that silently does less is far more common than one that errors.
  • Know the line that proves the work happened, and look for it. Ours prints two specific lines when the code is found; their absence was the real signal.
  • Test the outcome, not the exit code. One request to one address would have caught this immediately.
  • Be suspicious of fast. Work that finishes much quicker than usual has often found less to do.

The honest version

We lost a while to this, because the deployment kept saying complete and we kept believing it. The fix was moving a folder and the diagnosis was everything.

If a process in your business reports success and you have never checked what it actually produced, that is the one to look at this week.

Recognize this in your own systems? That is usually where we start.

hello@mcpeerigan.com