A plugin error almost published a page with an empty body

What happened

A site of mine is built from plain markdown files. Some pages contain a short custom tag in the text, and a markdown plugin turns that tag into the finished markup when the site is built. In September 2026 I was changing that plugin, and while doing it I found out what happens when it fails.

When the plugin threw an error, the build did not fail. It passed. The page the error happened on was still produced, but its body came out empty. Nothing else about the build said anything was wrong.

Step	What it reported	What was true
Markdown plugin on one page	Threw an error	That page could not be rendered
Site build	Passed	One page had an empty body
Publish	Nothing to stop it	An empty page could have gone out

No page went out empty. It came close, and it was found during the change rather than by a reader.

Why it is easy to miss

The common assumption about a build is simple: if something breaks, the build fails, and a failed build stops the release. That assumption is reasonable for errors that a build treats as fatal. It says nothing about errors that a build absorbs.

Here the error stayed inside one page. The build’s status was honest about the build, which did finish, and silent about the one page that had lost its content. Anything downstream that only looks at “build passed” would have treated the result as good.

The general shape is common in automation of every kind: a step that fails quietly inside a step that reports success. The outer step’s green tick is true about itself and tells you nothing about its parts.

What I changed

Two rules came out of it:

1. The plugin must not throw. When it runs into a problem, it leaves a marker in the output instead of raising an error that the build swallows.
2. The audit looks for the marker. The site already had an audit that checks the built pages. It now flags that marker as a must-fix.

The idea behind both rules: do not rely on the build to report a problem it does not consider a problem. Put the evidence into the output, then check the output.

What this has to do with hiring someone

Most automations you hire someone to build have steps inside steps: a workflow that calls an AI model, a script that fills a template, a sync that maps fields between two apps. Any of those inner steps can fail in a way that the outer step reports as success. A report arrives with one empty section. A message sends with a blank field. A row is written with nothing in it. Every run log says the job finished.

When you test a delivery, check the result itself, not only the green tick. Open the report, read the message, look at the row. The acceptance checklist for unattended automations includes forcing a failure on purpose; when you do, force one in the middle of the chain as well as at the start, and see whether you hear about it.

It is also worth a line in the brief. Ask how each custom part behaves when it fails, and ask for one final check that fails loudly when the output is empty or marked as broken. The guide to error alerts in an automation brief has wording for where those failures should be reported. And if the job runs with nobody watching, a heartbeat check is the outside view that notices when the expected result never arrives at all.

None of this needs a bigger budget. It needs one question asked before the build starts: when a part of this fails, what does the output look like, and who finds out?