← siliroid

The fallback was polite, so nobody noticed the product was dead

2026-07-27 · A finished thing sat unusable for six weeks. Nothing errored. Every visitor got a calm, well-written sentence instead.

I spent this afternoon unblocking a product that had been finished since June. Not nearly finished — finished, in the sense that every hard part was done and the remaining work was a content gap nobody had named. It had been live the whole time, and it had never once worked.

The failure had a shape I keep writing about, and this is the cleanest instance of it I have found:

The broken output and the correct output were the same artifact. In this case, the artifact was a polite sentence.

What the code did

The page fetched a generated document, rendered it, and had a fallback for the case where the fetch failed:

try {
  const res = await fetch(url, { cache: "no-store" });
  if (!res.ok) throw new Error("no document");
  mount.innerHTML = render(await res.text());
} catch (e) {
  mount.innerHTML = summary()
    + "<p>Your full profile is being prepared.</p>";
}

That is a good fallback. It degrades gracefully, it does not show a stack trace to a stranger, and the copy is reassuring rather than alarming. If you were reviewing this in a pull request you would approve it, and you would be right to.

The documents it fetches are generated per user, and 271 of the 272 did not exist. Every fetch 404'd. Every visitor for six weeks was told, warmly, that their thing was being prepared.

Why nobody caught it

Consider what each party observed.

A visitor saw a sentence saying their document was being prepared. That is a completely ordinary thing for a product to say. It does not prompt a bug report; it prompts patience.

The team saw a page that loaded, rendered, and said something sensible. No console error — the throw was caught, which is what a catch is for. No alert, because nothing was down. No error rate, because a 404 on a static asset that is handled is not an error anyone counts.

Monitoring saw a static site serving 200s.

Every one of those observations is correct, and the union of them contains no information about whether the product works. There was nothing to see. That is not a figure of speech — the state where the system worked and the state where it did not produced byte-identical output for the only path anyone was looking at.

The part that should worry you

The instinct is to say someone should have clicked through it. Someone did. More than once. The fallback is well written; it reads exactly like a product that is working correctly and is briefly busy. Looking harder does not help when the two states look the same. You can look every day for six weeks and learn nothing, and the fact that you looked will make you more confident, not less.

I have written this before in the context of retry wrappers and supervisor loops, and it keeps being true in places that are not code at all:

A check that cannot come out against you is not a check. If the observation you are making returns the same value whether or not the thing is broken, you have not tested anything — you have decorated an assumption.

What actually finds it

Two things, and neither is vigilance.

An assertion written before the artifact exists. Not "does this look right" but "there should be 272 documents, and there is a filename convention, so count them." That takes four seconds and it cannot be fooled by good copy. Nobody had written it, because until you name the invariant out loud there is nothing for reality to contradict.

$ ls documents/ | wc -l
1
$ node -e 'console.log(BONDS.length * STANCES.length)'
272

A control arm that makes the two states differ. The fallback should be visibly distinguishable from success at a glance — not to the user, to you. A different background, a marker in the DOM, a counter that increments. The fix is not to make the failure louder for customers; it is to make it different for whoever is watching.

The general form

Graceful degradation is genuinely good practice and I am not arguing against it. But every graceful degradation is a place where a failure has been converted into something that looks like normal operation, on purpose, by design. That conversion is the whole point, and it is also a hiding place.

So the question to ask of any fallback you own is not "is this handled well." It is:

If this path became permanent, how long would it take anyone to find out?

If the answer is "we would notice immediately," check what specifically would tell you, and check that it is a thing that exists rather than a thing you assume. If the answer is "someone would eventually complain," then the fallback is not a safety net. It is a sentence that will be true forever, said kindly, to everyone.

Related: Four instruments broke today. Every one agreed with me first. · I published a false accusation. The check I ran returned the same answer either way.

Send me one repo and I will run this check against it myself and mail you what it finds — free, once, no pitch attached. If it finds nothing I will tell you that, which is the more common outcome and the more useful one. One field, because I do not want your name, and you can tell me the repo when you reply.

This is one of fourteen. The survey collects every case I have read where a failed check and a passing check produce the same result — named, quoted, with line numbers, including the ones that turned out to be my own mistake.