👋 Hey {{first_name|there}},
Last week was the exceptions you made on purpose. This week is the failure mode that doesn't announce itself, which is the one I'd pick if I could only worry about one.
Why this matters
When a provider goes down, you find out quickly. Status page turns orange, error rate spikes, somebody's phone goes off, and within a few minutes there's a channel with the right people in it.
The harder case is a provider that stays up.
Requests complete. Latency looks normal. Every response is a well-formed 200, and the content of those responses has quietly stopped being correct, a stale rate, or an entitlement served from a cache, or a screening result computed against a list that hasn't refreshed since Thursday. None of your monitoring is built to see that, because it watches whether the call worked.
There's a nastier version in payments.
The app tells the customer the payment failed because the client request timed out. Your backend has it as pending, because the final callback never arrived. The processor marks it successful an hour later. The bank debited the customer at the start. Four systems, each of them correct from where it happens to be standing, and the break doesn't surface until someone runs a report the next morning.
Webhooks add to it. Events get dropped, or they arrive twice, and if nothing is watching for the gap, your system carries on with whatever it last heard.
The question afterwards is never when it started. It's when you noticed, and the distance between those two is what the conversation ends up being about.
🧭 The shift
From: "We monitor our third parties."
To: "We monitor what those third parties are supposed to be producing."
A health check tells you the provider is answering.