Every Check Passed

The essays page looked fine. Cards in a grid, newest first, a tidy end. What it did not show was most of the essays. They were built, they were live at their own addresses, and nothing on the page pointed at them. No pagination. No older posts. Just the newest batch and then the footer, on production, and the field notes and the journal the same way.

Every check passed. Tests, link checker, build, deploy. Green all the way down.

Landing page	Listed	Published
Essays	20	78
Field notes	20	61
Journal	20	31

The bug itself was small. The landing pages never told the listing how many pages there were, so it drew the first one and stopped. The bigger question was the other one. Why did nothing notice? I went looking, and that same week turned up five more checks on this site that could not fail.

Six checks that could not fail

Check	What it seemed to say	What it was doing	Now
Listing pages	every link works	never visited the posts that had no link	counts what is published against what the page reaches
Search engine ping	changed pages sent to Bing after each deploy	waited on two variables nothing ever set; never ran	tests the variables the script actually sets
Post-deploy check	the deploy was verified	ended in `
Staging	breaks before production does	sent no security policy at all	its own copy of production's policy, rebuilt every deploy
Build stamp	clean or dirty	said dirty on every build	dates from git history; writes only on change
Link graph	which posts are curated	counted the generated related-posts links	measured on the built pages

The listing pages were the purest case. Every check looked at what was there. The link checker walked every link, and every link worked, because the essays with no link were simply never visited. A test that walks what exists cannot see what is missing. The check that catches it has to count.

The ping had never run. Not once. It sat behind a condition on two variables that nothing in the script set, and its silence looked exactly like success.

The check after the deploy was worse, because it had a history. It ended in || true, so whatever it found, the deploy said Done. Before that it had misread its own output and called every page a failure. Later it tested two old addresses that redirect on purpose, and every deploy ended in two red marks that meant nothing. A red mark that always shows up trains you to stop reading red.

Staging is supposed to break first. The one failure that has ever blanked this site is a security header: the policy allows inline scripts by their hash, and a changed script with a stale hash leaves every page empty. Staging sent no policy at all. It could not show me that failure, by design, however many times I deployed to it.

The build stamp is a little flag that says whether the build came from uncommitted work. It said dirty every time, because the content cache wrote the clock into itself. A light that is always on is not a light. I had stopped looking at it.

And the link graph, the one behind the live map of this blog, which I use to see what the hub pages and cornerstones actually point at. It counted the related-posts block the site generates under every post, so it called things curated that only a machine had linked. One book review, by its count, linked a whole shelf of other reviews. Read the review and it links a handful. Measured on the built pages, the picture was thinner, and it changed what I worked on next.

All green

None of these was broken the way a crash is broken. Each one ran. Each one answered. The answer was reassuring whatever the site was doing.

That is worse than having no check. I believed things about this site that nobody had tested.

So now I ask a check a few things before I trust it. Can it fail? I make it go red once, on purpose, and if I cannot, it is decoration. When did it last fail? Something that has never failed is guarding a stable thing or guarding nothing, and I want to know which. What does it count? Every link works and every post is linked sound alike and are different claims, and most of what I had written was the first kind. Does it run where the failure happens? A header check against a server that sends no headers checks nothing. And does its answer reach a decision, or does it end at || true?

What changed

The listing gate counts now, and blocks the deploy on any gap. The ping tests what the script really sets. The check after the deploy is told where it is, staging runs it too, and a failure fails the deploy with a note that the files are already up. Staging carries its own copy of production's security policy, rebuilt on every staging deploy, so anything that would break production breaks there first, without staging ever touching production's policy. The content cache takes its dates from git instead of the clock, so two builds in a row come out identical, and the build stamp finally read clean, late at night, on a deploy that had stalled when the laptop battery died and picked itself back up when the machine woke. The link measurement reads the built pages, and every deploy now warns about a new post that hangs from nothing.

Three more, the week this went out

I held this post for a week while I reworked the deploy, and the deploy handed me three more before it was done.

Check	What it seemed to say	What it was doing	Now
Lighthouse on staging	scores every staging build	failed on every run since the day it was written, with "no URLs provided", behind a tail and an ||	serves the build itself and prints the four scores
A warning in the staging script	warns on a dirty tree	called a helper the production script has and the staging script never did; only ran on a dirty tree, and every test had been clean	the helper exists; the warning shows
The staging upload	puts the build stamp up	the quick upload listed five file types and the stamp was a sixth	the stamp is on the list

The Lighthouse one had the longest run. Every staging deploy for months printed a stack trace, three lines of it, and then a yellow line about warnings, and the deploy said Done. I had read that yellow line dozens of times as "some score dipped" when it meant "nothing ran." The second one is the kind that only fails when you are not looking: a code path that every clean test walked past, and a dirty tree the first time it mattered. The third was mine, the same afternoon, a feature that could not reach the place it was meant for because an allow-list written long before it did not know its name.

Same shape as the six. They ran.

Who found them

Not me, reading code. An agent and I were doing other work on the site, and each of these surfaced because something did not add up: a count that felt short, a line missing from a deploy log, a warning from a script we had just pointed at staging. Most were fixed in the same session that found them.

Some of these I wrote a long time ago. The ping was written by an agent days before I found it, and I had read it. Both kinds got through for the same reason. They ran.

An agent writes a check fast, and it runs. Whether it can fail is a separate question, and nothing in the loop asks it unless I do. I wrote last week about a comparison that failed quietly and still handed back a number, and before that about a month of numbers in my music studio that were measuring the thing next door. Same lesson, nine times over, on a site I thought I knew.

How many more are green right now?

Related reading: DevOps Beyond Automation, on why understanding the system is the part that compounds.