Two of my guardrails reported clean for weeks. Neither of them was capable of reporting anything else.
That is a different failure from a broken check. A broken check throws an error and you go fix it. These returned the exact output you get when everything is fine, so I read them as confirmation and moved on.
The grep that searched for a string nobody has ever written
We have a house rule against em dashes in published text. To enforce it on myself I grepped my own diffs:
grep -c $'—\|–' file.md
Zero. Every time. The rule looked healthy for months.
On macOS, BSD grep in basic mode treats \| as two literal characters instead of alternation. So that pattern searches for one literal five-character sequence, —\|–, which appears in no file I will ever write. It returns 0 for a file stuffed with em dashes and 0 for an empty file. Those two zeros look identical.
The version that works:
grep -c -e '—' -e '–' file.md
The interesting part is not the escaping rule. It is that I treated a zero as evidence without once asking what a non-zero would have required.
The analytics tag with nobody to send the hit
Most web analytics snippets have a "defer" or "manual pageview" mode. You turn it on when your app is a SPA, because you want to control when a view is counted instead of letting the loader fire on script execution.
Turning it on has a second effect that is easy to forget. The loader stops sending the initial pageview too. From that moment the counter reports only what your code explicitly sends.
If your code never sends anything, the outside view is indistinguishable from a working install:
- the script loads, 200
- the counter appears as "installed" in the vendor dashboard
- no console errors
- no failed requests, because a request that is never made cannot fail
You get an empty dashboard, and an empty dashboard has a much more likely explanation available: nobody visited. That explanation is wrong and it is very comfortable.
The 20-second probe, using Yandex Metrica as the example, works the same way for most vendors:
open any page with ?_ym_debug=1
console must print: PageView. Counter <id>.
If that line is missing, nothing is being counted, whatever the dashboard says.
The fix is two lines and the comment above them matters more than the code:
// The counter runs deferred because this is a SPA and route changes are
// not document loads. Deferred means the loader sends NOTHING on its own.
// If you ever remove `defer`, remove this call in the same commit, or every
// view is counted twice.
export function trackPageView(url: string, referer?: string) {
window.ym(COUNTER_ID, "hit", url, referer ? { referer } : undefined);
}
Two settings that must agree, living in two files, with no error on either side when they disagree. That is the shape of the problem.
What both of these have in common
Neither check had a failing case I had ever observed.
I had never seen the grep print a number greater than zero. I had never seen the analytics dashboard show a number at all. In both cases the absence was the expected output of the healthy state, so it carried no information, and I kept banking it as good news.
Three habits came out of this, and they are cheap:
Feed the check something bad on purpose. Before trusting a linter, a grep, a hook, or an alert, hand it input that must trip it. If you cannot make it fail, you do not have a check. You have a constant.
Be suspicious of zero specifically. Zero errors, zero matches, zero events. Every one of those is also what a disconnected pipe returns. A pipeline that reports "3 problems found, 3 fixed" tells you it ran. A pipeline that reports nothing tells you nothing.
Verify at the far end, not at the near end. "The script returns 200" is a fact about your server. "The console prints PageView" is a fact about the thing you actually wanted. They are not the same fact, and only the second one is worth anything.
The pattern generalises past these two. Alerts wired to a metric nobody emits. Retry logic behind a condition that is never true. A test asserting a mock. In each case the system reports health, because reporting health is the only thing it can do.
I write about the ugly parts of running an assistant product on top of WhatsApp and Telegram at dosai.pro. The public API and MCP server are documented at dosai.pro/docs/guide/08-developers/80-public-api.
Top comments (0)