"Not switched on" is not "broken"
A feature that refuses because it has not been set up, and a feature that falls over, look the same to whoever is standing there. They need different words, and different colours.
We fired every write operation in this product at a test database this week to see which ones fall over. Four hundred and two of them. One failed on purpose — more on that in a moment — and five refused.
The five refusals were all the same kind of thing. No text-message account is configured, so resetting a till code by text answers: "Code resets by text aren't switched on yet — ask your manager to set you a new code." No image storage is enabled, so uploading a photo answers: "Image storage isn't switched on — enable it, then redeploy."
None of those is a bug. Each is a decision the software made and explained. And the thing that made the run readable was that they are not shaped like failures: a refusal carries a different status code from a crash, so a hundred checks can be told apart from each other automatically.
Why the distinction earns its keep
Say a member of staff taps send me a new code and nothing arrives. If the screen said "something went wrong", the right response is to tell somebody technical, who will spend an afternoon looking for a fault that does not exist. If the screen said "this isn't switched on — ask your manager", the right response is to ask your manager, and the whole thing takes a minute.
Identical outcomes, completely different costs, decided entirely by the wording.
Three rules we hold ourselves to
Name the step, not the hole. "Not configured" describes our side of the problem. "Ask your manager to set you a new code" describes the reader's next move.
Never pass the technical message through. When something upstream of us fails, whatever it said is for our logs. A guest looking at a menu should not see a provider's error text, and we spent a release making sure they cannot.
Say which switch. "Enable image storage, then redeploy" tells the one person who can act exactly what to act on. A message that says "unavailable" makes them guess.
The one that fails on purpose
The single deliberate failure in those four hundred and two is a button on our errors screen whose entire job is to break. It exists so an owner can prove the alerting works without waiting for a real outage — press it, and a real alert should arrive by the normal route.
That button is now checked positively: our tests assert that it still fails. It sounds like a joke and it is not. An alerting test that quietly stops failing is worse than no alerting test at all, because now you have evidence — you pressed it, nothing happened, everything must be fine.
Every safety net you own should be questioned the same way. A fire alarm nobody has heard is an assumption. A backup nobody has restored is a folder. A reader who can tell "off" from "broken" is the difference between a system you can run and a system you have to interpret.