A provider is down
An outage is handled by waiting, not by working around it. Transient failures are retried, the mail read position is not advanced over anything that was not stored, and no message is recorded as sent without the provider's own acknowledgement. The most useful thing a person can do is resist resending, because a duplicate is the one damage an outage cannot cause on its own.
What the symptom looks like#
Work slows or stops on one channel while everything else behaves. Sends fail or sit in an uncertain state; a sync returns nothing new for longer than usual; calls do not connect. Screens keep working, because reading your own stored data does not depend on the provider that is unwell.
An outage is not the same as a disconnection. A disconnection is a credential the provider refuses; an outage is a provider that cannot answer anybody. The difference shows in the reason recorded against the failure, and it matters because one needs a person to reconnect and the other needs a person to wait.
What Connect does automatically#
- Retries the kinds of failure that are worth retrying. A timeout or a temporary error is retried on a later tick; a refusal for quota or a rejected key is not, because repeating it changes nothing.
- Holds the mail read position behind anything it could not store, so an outage delays messages rather than skipping them.
- Refuses to call a send successful without the provider's own evidence. An unacknowledged send is recorded as uncertain, which is deliberately a different word from sent.
- Closes call rows that nothing can end any more, and charges what it closes, so an interrupted call does not sit active for hours.
- Leaves follow-ups due rather than failing them, and retries a phone follow-up whose line is not ready about an hour later.
What Connect completed#
- Everything that reached a provider and was acknowledged is done and recorded as done, with the evidence attached.
- Everything ingested before the outage is canonical and answerable — the Assistant, search and the grid all work normally against it.
- Decisions taken during the outage, including refusals, are recorded with their reasons.
- Reservations spent on work that then failed were released, so the day's allowance was not consumed by messages nobody received.
What Connect did not complete#
- Messages prepared during the outage were not delivered. They are held, in order, with their approvals intact.
- Nothing new was ingested from the affected provider, so the workspace's picture of a conversation may be one message behind reality.
- Sends whose acknowledgement never arrived were not confirmed. They are uncertain rather than sent, and that state is a question for a person, not a fault.
- No alternative route was invented. Connect did not send by another channel, another mailbox or another number to get around the outage.
What you can do — and what to avoid#
Check whether the failure is an outage or a rejected credential.
Result You know whether to wait or to reconnect, and those are the only two useful responses.
Leave uncertain sends alone until the provider is answering again.
Result The state resolves with evidence rather than with a guess, and no duplicate is created.
If something is genuinely urgent, act as a person on a channel that is working, and note it on the thread.
Result The record shows a human handled it, so Connect does not later send the held reply as though nothing had happened.
What an administrator can do, and when to escalate#
An administrator can move an outbound role to a mailbox on a different provider, narrow autonomy so that nothing new is prepared while the backlog is worked off, or turn a channel off deliberately rather than letting it fail repeatedly. All three are reversible and all three are recorded.
Escalate when the provider is demonstrably answering — its own status is healthy, and a manual action through it succeeds — and Connect is still not completing work on that channel. That combination is not an outage, and the useful evidence is the time of the last successful operation and the reason recorded against the most recent failure, without raw provider text or identifiers.
Questions#
Does an outage consume my allowance?
Not for work that failed. A reservation made for a send that then fails is released, so an outage does not spend a day's allowance on messages nobody received. Work that succeeded before the outage is counted, as it should be.
Why is a message marked uncertain rather than failed?
Because the two are genuinely different. A failure is known not to have arrived; an uncertain send may have arrived without the acknowledgement getting back. Recording it honestly is what lets a person check before creating a duplicate.
Will held work go out automatically afterwards?
Yes, through the same boundary it would have used, subject to the same autonomy rules and allowances. What it does not do is re-decide: a reply held for a day answers the message as it stood then, so read before releasing a large batch.