Your channel says "healthy" — and it hasn't sent a message in hours.

A messaging channel with a session behind it — WhatsApp Web, a paired device, an OAuth-backed API — can go dark while the process stays up. /health answers "is the process alive," not "can this thing actually deliver," and those are different questions that quietly diverge.

The crux

We hit this running our own WhatsApp automation in production: the paired device went unauthenticated (needed a fresh QR scan) while the service process kept running untouched. The only check most /health handlers implement — is the process alive and answering HTTP — stayed green the entire time. Outbound messages queued instead of failing loudly; the first real signal was silence, not an alert.

function naiveHealth(channel) {
  return { ok: channel.alive };
}

That's a correct answer to the wrong question. The one that matters for anything session-based: is the session behind this endpoint currently authenticated, and has it proven that recently by actually sending something?

Run it

node check.js --demo

Zero dependencies, no network — reproduces the class in ten lines: a channel that's alive, unauthenticated, and hasn't sent anything in 6 hours, checked two ways.

Against your own health endpoint (built-in http/https only, still zero deps):

node check.js --url http://localhost:PORT/health [--field authenticated]

It tells you one of three things: the JSON has no authenticated-state field at all (this failure class is invisible to you today), the field says false while the HTTP status says 200 (the false green, live), or the two agree.

The fix is two-part

• Add an authenticated-state field, not just a process-alive one — alongside whatever ok already means.
• Add a recency check. A stale authenticated: true left over from before a session silently expired is exactly as misleading as not checking at all — pair it with a "proved it worked recently" timestamp and fail once that goes stale.

Skip the second part and you've only moved the false green one hop later — from "checks liveness" to "checks a flag that never gets updated."

Check your own system

• Does your /health distinguish "process is up" from "the session behind this endpoint is currently usable"?
• If the underlying session expired an hour ago, would your health check say so within minutes — or only once someone notices nothing is arriving?
• Is there a paired fallback that quietly shares the same underlying session? If so, "the fallback also went green" proves nothing — same single point of failure, second name.

Get the code