Nine failures that looked like nothing

We spent a week auditing our own product. Nine faults were live in production. Not one of them logged an error, showed a broken page, or failed a build.

They shared a single cause, and it is not the one you would guess.

The AI key had been invalid since deploy

Every AI call had been failing for weeks. The chat widget answered from a canned FAQ. The brief assistant returned a template. On every request, for every user.

Nothing looked broken, because every caller had a catch and a sensible fallback. The feature degraded politely into a worse feature, and a worse feature that still answers is indistinguishable from a working one unless you know what the good answer looks like.

The changelog rendered zero entries

The loader read data.entries. The file provided data.changes. So || [] returned an empty array and the page served a confident "What's New" heading above nothing at all.

Nobody noticed for months, and here is why: an empty changelog looks exactly like a working changelog on a quiet week. There is no visual difference between "we shipped nothing recently" and "this page is structurally incapable of showing anything, ever".

The audit log recorded nothing

The logging module had a considered API, clear types, and zero callers. Two admin pages read from it and had been permanently empty since the day they were built.

That is worse than having no audit log, because the page implies the events are being recorded. An empty table reads as "nothing happened".

The help centre opened nothing

Fifteen articles listed on the index. The titles were plain <span> elements — not links. There was no route for an individual article, and the function to load one had never been called by anything.

It did not 404. It did something quieter: it looked like a help centre until you clicked. And nobody clicks their own support pages.

Error messages were invisible in dark mode

The dark theme never defined its own colour for destructive text, so it inherited a near-black red from a palette that had been superseded. Every form validation message rendered at 1.84:1 against the background.

The text was there. The DOM was correct. A screenshot would show a form with, apparently, no error on it.

And a comment that was simply wrong

Our brand orange carried a code comment stating it gave "~4.6:1 on the cream background, so it is safe for body copy". It measured 3.81:1 — below the accessible minimum.

The claim was written once, was wrong, and was then believed by everyone who read the file afterwards. Including us, several times, before anyone measured it.

The common cause

Every one of these had a graceful fallback. A catch {}, a || [], a default value, a polite degradation. The engineering instinct that produced them is a good one: do not let one failure take down a page.

But a fallback converts a loud failure into a silent one, and silence is indistinguishable from success. You do not get an alert. You get a page that renders.

The pattern is not "we wrote bad error handling". It is that error handling *without a signal* trades a problem you would have fixed in an hour for one that lasts months.

What actually found them

Not code review. Every one of these faults is invisible in the source — the source looks correct, because it *is* correct in isolation. What found them was measuring the built artefact:

• Running an accessibility engine against the rendered HTML, not the components. 93 violations across 17 page templates.
• Computing contrast ratios from the theme tokens as the cascade actually resolves them, rather than reading the values.
• Fetching every URL in the sitemap and checking what came back.
• Comparing what the code advertises against what it registers.

That last one nearly caught us out in the other direction: a scan reported twelve commands declared but never registered. They were registered — dynamically, in a loop, in a way static analysis cannot see. We checked all twelve before reporting a single one. Measuring badly produces confident wrong answers just as efficiently as not measuring at all.

What we changed

The fallbacks are still there. We did not remove them; a page that dies because one widget failed is not an improvement.

What changed is that the important ones now say something. The health check has a third state — *degraded* means the site serves but a promise it makes does not. Contrast is asserted by 43 tests, so the next wrong number fails a build instead of shipping. Email is checked for a verified sending domain rather than the presence of a key, because the key was valid the whole time and every send still failed.

If you take one thing from this: go and fetch your own pages. Not the code — the pages. The gap between the two is where this whole category lives.