Reviewing mailbox health as a routine
Check three things per mailbox: that it is authorised, that mail is actually arriving, and that sends are being acknowledged. Connected proves only the first. A mailbox that authenticates and returns nothing is quiet, which is a signal rather than an error — and the count of mailboxes on the screen is itself worth checking against what you believe you connected.
Why connected is not health#
Authorisation and usefulness are different questions. A mailbox can hold a valid credential, answer every request successfully, and return no mail — because the account genuinely has none, because a filter is moving everything, or because the read position has moved past what arrived. All three look identical to a check that only asks whether the connection works.
So a review asks three questions rather than one, and the second and third are the ones that catch real problems.
The three questions, and what each answer means#
| Question | A good answer | A bad answer, and what it points at |
|---|---|---|
| Is it authorised? | The connection is current and the provider accepts it | Reconnection needed — the credential lapsed or was withdrawn at the provider, not here |
| Is mail arriving? | New messages appear in conversations at the rate the account receives them | Quiet: authorised and returning nothing. Check the account itself before assuming a fault in the sync |
| Are sends acknowledged? | Sent means the provider acknowledged it, with the evidence recorded | Uncertain, which is shown as uncertain rather than guessed. Resending on a maybe is how somebody receives the same reply twice |
The review, stage by stage#
- Trigger — a weekly slot, a report that mail is not being answered, or a new mailbox added.
- User event — somebody opens the mailboxes screen and reads every row, including the ones nobody has thought about for a month.
- Authentication and workspace resolution — every mailbox listed belongs to this workspace; there is no cross-workspace view for anyone.
- Ingest — each mailbox carries its own health verdicts, its role, its signature and its own autonomy setting.
- Canonical record — provider-shaped rows are bridged into the canonical conversations the engine and the screens read, so a provider fault cannot corrupt the history.
- Classification — authorised, quiet, refusing, or sending uncertainly. Each has a different action and only one of them is an error.
- Knowledge and rules — the allowance decides how much mail is processed; when it is spent, work is held rather than dropped.
- Approval — the read cursor deliberately does not advance on a refusal, so held mail is still there when the allowance resets.
- Action — reconnect, investigate, adjust the allowance or the roles, or do nothing because quiet is correct for this account.
- Result — every mailbox has a known state and a reason, rather than a colour somebody stopped reading.
- Relationship and timeline — conversations continue to attach to people regardless of which mailbox they arrived on.
- Audit and Needs You — refusals and health problems are in the queue, and each entry drains by itself as its cause clears.
The pattern that hides a mailbox completely#
The failure worth knowing about is a mailbox that is invisible rather than missing. A row whose workspace stamp is empty matches no scope and no security policy, so every list omits it silently while every action aimed directly at it still works. Two connected identities can disappear from the screen this way, with no duplicate warning and no error.
Both the list and the uniqueness check now ask a query that can see such a row, read-only. Repairing the stamp is deliberately not something a request can do: the write is refused by the security policy, so the repair belongs to the schema owner and runs at boot instead.
The action for each state#
- Needs reconnection
- Reconnect at the provider. The credential lapsed there, so nothing inside Connect will restore it. See Reconnect required.
- Quiet
- Check the account directly before treating it as a fault. A dormant address that receives nothing is healthy and quiet at the same time — see Mail not arriving when it should not be.
- Refusing on allowance
- Nothing is lost: work is held and the read position stayed put. Decide whether the allowance matches the volume, or whether a burst was exceptional.
- Sending uncertain
- Confirm at the provider before resending. The record says uncertain because the acknowledgement never arrived, not because the message definitely failed.
- Write-back failing
- Low priority by design: a failure to mark read or apply a label never blocks the reply itself, so mail keeps flowing while it is investigated.
- Fewer rows than expected
- Do not reconnect. Count, then investigate — reconnecting an account whose row is invisible is how one inbox becomes two records.
Questions#
How often is a review worth doing?
Weekly for a workspace with several mailboxes, and immediately after adding one. The queue raises the acute problems by itself; the review catches the quiet ones, which by definition raise nothing.
A mailbox says it is connected but nothing has arrived for days. Where do I start?
With the account itself, in its own provider interface. If mail is genuinely arriving there, the question becomes the read position and the sync; if it is not, the mailbox is quiet and correct, and the problem is upstream of Connect entirely.
Does each mailbox have its own rules?
Yes. Role, signature and autonomy are per mailbox, and autonomy resolves at the narrowest scope that applies — so one address can hold every reply for approval while another sends. That is often the reason two mailboxes behave differently on the same day.