The mailbox disconnected

What the symptom looks like#

• The mailbox row shows a disconnected or failing verdict, and an entry appears in Needs You.
• The last-sync time has stopped moving — that is usually noticed before the verdict is.
• New conversations stop arriving, while old ones remain complete and readable.
• Replies from that mailbox fail, or an approval sits in Needs You after being approved.

The one symptom that is *not* this fault: a mailbox that authenticates normally and returns nothing. That is a quiet mailbox — a health signal meaning nobody has written, and the last-sync time keeps moving.

The recovery, stage by stage#

1. Trigger — a fetch or a send fails to authenticate against the provider.
2. External event — almost always something outside Connect: a revoked grant, a rotated password, a changed provider policy.
3. Authentication and workspace resolution — the failure is attributed to one mailbox in one workspace; every action on the row goes through mailbox_console.row_for.
4. Ingest — the fetch stops. What it had already written stays written.
5. Canonical record — threads, messages and contacts are untouched; a credential failure changes no conversation.
6. Classification — the failure is recorded as a credential problem rather than as a message-level error.
7. Knowledge, memory and rules — untouched; a mailbox keeps every rule set against its endpoint tier.
8. Autonomy and approval — held work stays held under the same rule it was held by.
9. Action — a person reconnects the existing row: re-consent for Google, replaced settings for IMAP.
10. Result — the credential is resealed and the mailbox authenticates again.
11. Relationship, timeline and memory — nothing was detached, so people and companies pick up where they stopped.
12. Audit, usage and Needs You — the reconnection is recorded and the Needs You entry drains by itself once its cause has cleared.

Causes, most likely first#

1. A revoked or expired grant. Somebody removed Connect's access in the Google account, or the grant stopped refreshing. This is the common one, and reconnect required covers what a re-consent does and does not restore.
2. A changed password on an IMAP or SMTP account. The stored settings are now wrong. They are sealed and never echoed back, so the fix is to replace them rather than to inspect them.
3. A provider-side policy change. Two-factor authentication turned on, an app password revoked, or a security setting that now refuses the connection.
4. A network or host change. A mail host that moved, a port that is now blocked, or a certificate the connection will not accept.
5. Not a disconnection at all. A row whose workspace stamp is empty matches no scope, so it disappears from the Mailboxes screen while by-id actions on it still work. That looks like a vanished mailbox rather than a failing one, and it is repaired by the boot-time migration.

What Connect did complete#

• Everything fetched before the failure is bridged into the canonical tables and is readable.
• The read cursor is where it was, so the next successful sync resumes from the first unprocessed message rather than skipping ahead.
• Held drafts, approvals and dated commitments are intact and still governed by the same rules.
• The failure is recorded, and Needs You shows it rather than leaving it in a log.

What Connect did not complete#

• No mail was fetched after the failure. It is still at the provider, and it will be fetched on the next successful sync.
• No reply left the mailbox. A send that failed stays as a failed record against its thread and is not retried silently.
• No write-back happened, so read state and labels at Gmail are behind. That is cosmetic: write-back is best-effort and never blocks a reply.
• Nothing was deleted anywhere — not in Connect, and not at the provider.

What you can do, and when to escalate#

1. Open the mailbox row and read the verdict, then check the provider directly in its own web interface.

   Result You learn whether the account itself is healthy before changing anything in Connect.

2. Reconnect the existing row. Do not add a mailbox.

   Result Role, signature, autonomy and history survive; a second row for one inbox does not fix anything and creates two cursors.

3. Sync, then send one message.

   Result Both halves are proved. A mailbox that reads and cannot send is a different fault with the same verdict.

An administrator can additionally check whether the grant was revoked in the organisation's Google account rather than by the mailbox's owner, whether a security policy now requires an app password, and whether the mailbox is one of several identities where only one has failed. Escalate when the provider reports the account and its access as healthy and the mailbox still refuses to authenticate after a fresh consent — at that point the evidence needed is the verdict and the timing, never a raw provider error containing identifiers.

Questions#

Related#

• Disconnecting a mailbox
• Repairing a broken mailbox, end to end
• Reconnect required
• Mailbox health
• Mail is in the provider but not in Connect
• Why 'connected' is not enough to prove mailbox health
• A row with no workspace stamp is invisible, not missing