Everything returned 200. Four leads still went nowhere.

Three things broke on my own projects this week. Not one of them produced an error message. Every single call returned a success code, every log line looked healthy, and in two of the three cases the failure had been running quietly for weeks.

That's the pattern I want to write down, because it's the expensive one. Loud failures get fixed on the day they happen. Polite failures sit there.

One: the lead that had nowhere to go

A directory site I run forwards enquiries to the listed business. The routine looks up a recipient address, and if it can't find one it emails me instead and returns false. Reasonable behaviour, on paper.

What actually happens is that the enquiry stays flagged as new, never gets marked as forwarded, and quietly expires after thirty days. The person who wrote in hears nothing. The business never learns the enquiry existed. And the alert I get is a one-liner saying a code has been stored, not the enquiry itself — so acting on it means going and digging.

When I looked, this was the fourth time. Not the first.

The real defect was one level further back. The research pipeline that builds the listings collects name, address, postcode, phone and website — and no email address. Every listing imported that way is a hole with a trapdoor over it. The business I was trying to reach had its address published on its own contact page the whole time.

Two: I was invisible in my own analytics

Same site. The funnel showed almost nothing, and my own test payment never appeared. My first explanation was an ad blocker, which is the comfortable explanation because it makes the tool the problem.

It was in the theme code. The analytics tag is only printed for visitors who aren't logged in. I'm permanently logged into my own site, so none of my sessions were ever measured. In the browser the tracking object simply didn't exist; fetching the same URL without cookies returned the tag perfectly.

The side effect is worse than my missing test. That rule excludes every logged-in user — including the paying partners with accounts, who are precisely the people whose behaviour I most want to understand. An exclusion written to keep the editor's own clicks out of the data had quietly redefined what the business is able to see. Which is the same disease I've written about before: a dashboard doesn't lie by putting wrong numbers on the screen, it lies by leaving things out.

Three: the API that agreed with me and did nothing

To patch the missing email addresses I sent an update through the site's REST API. Status 200. Response body fine. Field still empty.

The endpoint accepts custom fields it doesn't actually persist. No error, no warning, no hint — just a polite success for work it never did. If I hadn't re-read the record afterwards, I'd have logged that as fixed and moved on.

Which is the only real defence here. A 200 means the request was received and processed. It does not mean the thing you wanted to happen happened. Those are different claims, and the gap between them is where an entire afternoon of confident, wrong work lives — including AI-assisted work, which will happily report the same success back to you. I've been caught by this exact shape before, when a routine kept recreating the same task because nothing checked what already existed.

Nassim Nicholas Taleb, in Skin in the Game, calls it pathemata mathemata — learning through pain. His point is that the abrasions guide the learning. A system that fails without ever touching you teaches you nothing at all.

The fix isn't clever, it's just deliberate

Google's SRE handbook has a line I keep coming back to: a monitoring system exists to answer two questions, what's broken, and why. Alert on the symptom the user experiences, not on the internal cause you happened to think of in advance. If nothing in your system can produce the sentence "an enquiry arrived and nobody received it", then that failure is invisible by design, no matter how good your logs are.

So three changes, all boring. When there's no recipient, the record gets marked blocked instead of new — a state that looks wrong at a glance rather than one that looks like it's waiting. The alert carries the full enquiry, so forwarding it by hand is a copy and paste rather than an investigation. And a weekly sweep lists anything that was never forwarded, because the only reliable way to catch a silent failure is to go looking for it on a schedule.

The exclusion rule changes from "is this person logged in" to "can this person edit the site". Same intent, tenth of the collateral damage.

The thing that actually stayed with me

The enquiry that triggered all this wasn't a new customer at all. It was an existing one, asking whether he should water the ground before the crew arrived the next morning. He used the enquiry form because the free profile hides the phone number.

The paywall caught the wrong person. It was built to make sure new business gets paid for, and instead it stood between a company and its own customer on a time-sensitive question. Nobody designed that. It emerged from two reasonable rules meeting.

I forwarded it, free, and told the business it happened. Then I wrote down the design question, which is the more valuable output: should a free listing really hide the phone number from everyone, including the people who already know who you are?

Build things that shout when they break. Silence is not the same as fine — and neither is a green checkmark.

Sources & further reading

External
Monitoring distributed systems — Google SRE book, on symptom-based alerting and the difference between what's broken and why.
200 OK — MDN Web Docs, on what a success status actually asserts.

Related posts
The form promised a copy by email. Nobody was sending it.
My assistant created the same task three days running. The fix has a name: idempotency.
Your analytics dashboard is lying to you by leaving things out
Which zeros were real