# An integration disconnected

A disconnection means the credential Connect holds is no longer accepted by the provider. Everything already fetched stays; nothing new arrives; and outbound work on that connection is refused rather than queued indefinitely. Repair happens at the provider, because consent withdrawn there cannot be restored from here — Connect never holds a copy it could replay.

- **Status:** Available
- **Audience:** both
- **In the app:** #/mailboxes, #/integrations
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/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

| Connection | Usual cause | What repair involves |
|---|---|---|
| Gmail over Google | Access withdrawn in the Google account, a password change, or consent that lapsed | Consent again at Google, with the same scopes |
| Microsoft Graph | A tenant policy or an administrator removing the grant | Consent again, sometimes needing an administrator rather than the mailbox owner |
| IMAP and SMTP | A changed password, a withdrawn application password, or a server policy change | New credentials entered deliberately; the old ones are not recoverable from Connect |
| A messaging or telephony provider | Credentials rotated or a key revoked at the provider | Re-issue at the provider and save the new credential |

> **Note** Credentials are sealed when they are saved and are never echoed back to a screen. That is why a repair is always re-entry or re-consent and never 'show me what is stored so I can check it' — the value is not retrievable, by design.

## 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.

> **Careful** Do not resend by hand until you know a send was refused rather than uncertain. A send whose provider acknowledgement never arrived is recorded as uncertain rather than sent, precisely so that a person can check before creating a duplicate.

## 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

### Will mail sent to me while the connection was down be lost?

No. It stays at the provider until Connect can fetch it, and the retained read position means the sync resumes at the right place rather than skipping the window that was missed.

### Why can Connect not just reconnect itself?

Because the provider withdrew the permission, and only the provider can grant it again. Anything that reconnected without a person consenting would be storing a credential the provider had already decided to stop honouring.

### Does a disconnected mailbox stop the whole workspace?

No. Other mailboxes and other channels carry on. What stops is fetching and sending on that one connection, which is why role matters — an outbound role on a broken connection is felt more widely than an inbound-only one.

## Related

- [The mailbox disconnected](https://connectbyjbrh.com/docs/troubleshooting/mailbox-disconnected/)
- [Reconnect required](https://connectbyjbrh.com/docs/troubleshooting/reconnect-required/)
- [Mailbox health](https://connectbyjbrh.com/docs/email/mailbox-health/)
- [How provider credentials are stored](https://connectbyjbrh.com/docs/security/credential-sealing/)
- [Rotating a provider credential, end to end](https://connectbyjbrh.com/docs/workflows/credential-rotation/)
- [A copy of a password somebody else rotates](https://connectbyjbrh.com/research/stale-credentials/)

## What this page is based on

- docs-source/sources/GENERAL.md §10 — sealed credentials and the stale-copy failure
- `backend/app/tenant_inbox.py` — the retained read position
- `backend/app/metering.py` — mailbox slots as a resource ceiling
- Connect capability registry (docs-source/facts.py)