We Tested an Unreachable Recipient and the Send Still Said Success

We had a rule for who an urgent message should come from. It should go out under the name of the person or process actually built to act on it right away, not a shared, general line that could only pass the words along. The test we used to decide that was simple: if their own login still works, send it under their name.

A login is just a set of working credentials. It works whether or not anything is on the other end, active and able to respond. We could send a message under a name with nothing there to answer it, and the system would still report success. It would say the message went out correctly. Nobody would know the one thing that mattered, something being there to respond, wasn’t true.

Human handoffs fail the same way. The system reports success while nothing is able to act on what came through.

We went looking before it burned us

We hadn’t been hurt by this yet. We went looking for it on purpose, before it had the chance to matter. We made the intended recipient unreachable, left their login completely untouched, and sent a test message.

It went out under their name, formatted correctly, delivered successfully, with no one there to see it.

A working login only tells you the system accepted the request. It says nothing about whether anything is happening on the other end. Those are two separate facts, and we had built a check for exactly one of them.

What counts as proof that someone is there

The fix replaced the question. Instead of asking “does this person’s login still work,” the system now asks whether this person or process has checked in recently, on their own, on a regular schedule, somewhere we can see it whether or not sending them a message would succeed. If that recent check-in is missing, stale, or can’t be read for any reason, the system treats it the same way every time. It assumes nobody is there and falls back to the next option.

It doesn’t try to guess whether the person is unavailable, unreachable, or whether the check itself just failed for some unrelated reason. Whoever is waiting on the other end experiences all three exactly the same way: they think someone is coming, and no one is. Treating them as different cases and sending anyway is how a gap goes unnoticed for months.

The backup says it is a backup

The other detail mattered as much as the check. The backup path never pretends to be the original. When the intended recipient can’t prove they’re there, the message still goes out, but under a clearly different, clearly labeled line. It says plainly that the usual recipient appears to be unavailable and this is a backup. If even that fails, it drops to the plainest possible fallback, also labeled. Every step announces itself.

A backup that stands in without saying so fails silently for months, right up until the day it matters.

Who decides what

An assistant helped with one part of this: designing and describing the “are they there” check, and making sure every fallback step names itself accurately. It shouldn’t decide on its own that a working login is good enough proof, and it shouldn’t reroute an urgent message without flagging that it did.

A person decides what counts as proof that someone is available, and what an acceptable backup looks like when they aren’t. That is a judgment call about the cost of a missed message, and it belongs with whoever owns that risk.

A working login proves the door opens. It doesn’t prove anyone is behind it. For anything urgent, we now require a recent, independent sign of life, treat a missing or unreadable one as “nobody is there,” and label every backup route as a backup.

dxdev LESSON · paste into your AI agent

LESSON: Test for a pulse, not just a password

WHAT TO SHARE:
A de-identified description of how an urgent message currently gets routed to a person or team, and what the system currently checks before deciding who it goes to.

ASK YOUR AGENT TO:
1. State plainly what the current check actually proves versus what it's being trusted to prove.
2. Propose a fresh, ongoing signal that the intended recipient is actually available right now, not just that their account or line still works.
3. Design a backup path that clearly labels itself as a backup and states why, rather than silently standing in.
4. List the different reasons the primary recipient might be unreachable, and confirm they'd all be treated the same way by whoever is waiting.

RETURN:
A description of the gap between the current check and what it should prove, a proposed "are they actually there" signal, and a labeled backup plan.

BOUNDARY: Do not change how urgent messages are routed or turn any alert on or off. A person reviews the design and decides what to put in place.