An integration disconnected

The shape it always takes#

Whatever the provider, the sequence is the same: a call that used to succeed is refused for authentication, the connection is marked unhealthy, scheduled work on it stops, and the failure is surfaced for a person rather than retried forever. What differs between providers is only what caused the credential to stop being accepted.

The single most useful signal is the last time the connection succeeded, not whether it currently displays as connected. A stored credential that has been rejected all day still describes itself as configured, and a screen that only shows configuration cannot tell you the difference.

What each provider does differently#

What Connect completed#

• Everything fetched before the disconnection is stored and remains readable, searchable and answerable.
• The read position for that mailbox is retained, so reconnecting resumes from where it stopped instead of re-importing or skipping a window.
• Drafts written from the messages already ingested are intact, including any waiting for approval.
• The failure itself is recorded with its reason, so the connection's history shows when it stopped rather than only that it is stopped now.

What Connect did not complete#

• No message that arrived after the disconnection has been fetched. Those messages are still at the provider, not lost, and arrive on reconnection.
• No outbound message was sent on that connection. A send attempted against a rejected credential is refused, and a refusal is not a delivery.
• Nothing was written back to the provider — no label, no read state, no folder change.
• The connection was not repaired automatically, and no credential was guessed, reused or derived to keep it alive.

What you can do#

1. Read the connection's last successful time and its recorded reason.

   Result You can tell an authentication failure from an outage, which need different responses.

2. Reconnect at the provider — consent again, or enter the new credentials.

   Result The next scheduled run uses the new credential and resumes from the held position.

3. Let one sync complete before judging.

   Result The backlog that accumulated while the connection was down arrives in order, and a mailbox with a day of mail to catch up takes a moment.

What an administrator can do, and when to escalate#

An administrator can remove a connection that is no longer wanted, add its replacement, and change which mailbox holds which role so that outbound work moves to a connection that is working. Mailbox slots are a plan ceiling rather than a daily allowance, so removing before adding is sometimes necessary — and removing does not delete the mail already stored.

Escalate when reconnection succeeds and the connection fails again within the same day, twice — that pattern usually means something at the provider is withdrawing the grant rather than a one-off expiry. Report the times of each successful reconnection and the recorded reason for each failure; do not paste raw provider errors, which carry identifiers that do not belong in a support thread.

Questions#

Related#

• The mailbox disconnected
• Reconnect required
• Mailbox health
• How provider credentials are stored
• Rotating a provider credential, end to end
• A copy of a password somebody else rotates