# A channel provider going down

A provider outage surfaces as health rather than as silence. The channel's own signal — a mailbox that has stopped fetching, a line that is not ready — escalates into Needs You, outbound work on that channel is refused with a reason instead of being retried into a wall, and everything on the other channels carries on untouched. Recovery drains the held work by itself as the cause clears.

- **Status:** Available
- **Audience:** both
- **Channels:** email, whatsapp, sms, phone
- **In the app:** #/needs-you, #/mailboxes, #/calls, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/channel-failure/

## The chain

1. Trigger — a provider stops answering, rejects credentials, or starts refusing traffic it previously accepted.
2. External event — the first evidence is usually an outbound attempt that does not complete, or an inbound stream that stops producing messages.
3. Authentication and workspace resolution — unchanged. An outage affects the channel for the workspaces configured against that provider, and reaches no further; workspaces on other credentials are unaffected.
4. Ingest — for an inbound failure, nothing arrives. This is the hardest failure to see, because a quiet channel and a broken one look identical from the outside.
5. Canonical record — no new messages on the affected channel. Existing records are untouched: an outage never rewrites history.
6. Classification — the channel's own health check is what distinguishes quiet from broken. Mailbox health looks past 'connected' to whether messages are actually being fetched, and voice line health reports readiness rather than configuration.
7. Knowledge and rules — unchanged, and this matters during an outage: directives, suppression and standing instructions are held against people and the workspace, not against a provider, so they survive it entirely.
8. Autonomy and approval — untouched. An outage does not relax a rule; it removes the ability to act, which is a different thing and is recorded differently.
9. Action through a provider — attempts on the failing channel do not complete. What is not allowed to happen is an optimistic record: a send is sent only on provider evidence, so an outage produces unsent work rather than phantom deliveries.
10. Result — refusals and failures are recorded with their reasons. The Decision Log shows work that could not be done, not an absence.
11. Relationship and timeline — the person's record shows the gap honestly. Nothing is invented to fill it.
12. Audit, usage and Needs You — the health problem is queued for a person, and the entry drains by itself when its cause clears rather than needing to be dismissed.
13. Next — when the provider recovers, held work resumes under the ordinary rules, and anything that aged past its usefulness is closed rather than sent late.

## Detection: what is visible per channel

| Channel | How it surfaces | The failure that hides |
|---|---|---|
| Email | Mailbox health stops reporting a healthy fetch; a disconnect or reconnect prompt appears | A cursor that has stalled while the connection stays green |
| WhatsApp | Sends stop completing; inbound stops arriving | Provider-side limits that reject some traffic and accept the rest |
| Phone | Line health reports the line is not ready, and escalates into Needs You | A line that answers and then fails mid-call |
| SMS | Readiness already names the missing condition | Nothing new — outbound is unavailable on the live carrier regardless |

> **Careful** The hiding failures in the third column share one property: the channel looks configured. That is why [Verifying a channel actually works](/docs/workflows/channel-verification/) insists on real traffic rather than on an indicator, and why a long quiet period on any channel deserves a test rather than an assumption.

## What stops, and what carries on

- **Stops:** outbound attempts on the failing channel, and inbound arrival if the failure is on that side.
- **Carries on:** every other channel, in full. Channels share a canonical record and a set of rules; they do not share a provider or a failure.
- **Carries on:** the agent loop, working on everything already received. An outage on one channel does not pause reasoning about the rest.
- **Carries on:** suppression, directives and autonomy, which are workspace and contact facts rather than provider facts.
- **Carries on:** the record. Nothing is deleted, and no send is recorded that did not happen.

The refusal-with-a-reason is the part worth insisting on. A retry loop that hammers a dead provider produces two bad outcomes — a log nobody reads and a message that eventually arrives long after it mattered. Recording the refusal and surfacing the health problem puts a person in front of the decision while it is still theirs to make.

> **Note** No published threshold or timing for outage detection exists in these sources, so this page does not state one. What it can state is the behaviour: health rather than silence, refusal rather than a phantom send, and a queue entry that clears itself.

## Recovery

1. Fix the cause at the provider — reconnect the mailbox, restore the credential, or wait out the provider's own incident.
   - Result: Health starts reporting normally again on its next check.
2. Let the Needs You entry drain rather than dismissing it.
   - Result: Entries clear as their cause clears, so a queue that empties itself is evidence the fix worked; one dismissed by hand proves nothing.
3. Review what aged during the outage before releasing it.
   - Result: A reply that is now days late may need rewriting rather than sending, and a very late call-back is worse than none — the phone follow-up drain closes rows more than twenty-four hours late as missed rather than ringing somebody at the wrong moment.
4. Verify the channel with one real message before trusting it again.
   - Result: You have evidence rather than an assumption, which is the whole difference between a recovered channel and one that will fail again quietly.

## Questions

### Do messages sent during an outage arrive later?

Work held during an outage is resumed under the ordinary rules once the channel recovers, and it is re-checked at the send boundary when it is attempted rather than released blindly. Anything that has aged past usefulness is closed instead — a late message can do more harm than a missing one.

### Does an outage on one channel affect the others?

No. Each channel has its own provider and its own credentials, and the shared parts — the canonical record, memory, autonomy, suppression — are not provider facts. An email outage leaves WhatsApp and phone working normally.

### Will I be told, or do I have to notice?

Health problems escalate into Needs You, which is the queue a person is expected to work rather than a log they might read. The entry stays until its cause clears, and clears itself when it does.

## Related

- [Verifying a channel actually works](https://connectbyjbrh.com/docs/workflows/channel-verification/)
- [Configuring a channel, end to end](https://connectbyjbrh.com/docs/workflows/channel-configuration/)
- [Mailbox health](https://connectbyjbrh.com/docs/email/mailbox-health/)
- [SMS will not send](https://connectbyjbrh.com/docs/troubleshooting/sms-not-sending/)
- [Why 'connected' is not enough to prove mailbox health](https://connectbyjbrh.com/research/mailbox-health-beyond-connected/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §1 — mailbox health and the cursor
- `docs-source/sources/GENERAL.md` §5 and §7 — Needs You, line health, the phone follow-up drain
- Connect capability registry (docs-source/facts.py) — `mailbox_health`, `line_health`