Why 'connected' is not enough to prove mailbox health
"Connected" means a credential worked. It does not mean mail is arriving, the read position is moving, sends are being accepted, or the row is even visible on the screen that lists it. A mailbox that authenticates and returns nothing is a quiet mailbox — reported as a health verdict rather than an error, because most quiet mailboxes are correct and a few are not.
What a green connection actually proves#
It proves that a token refreshed, or that an IMAP login succeeded, at the moment it was checked. Everything a business cares about sits downstream of that, and each part fails independently.
| Signal | What it proves | What it does not |
|---|---|---|
| Authentication | The credential is current | That any mail is being read, or that the account still receives any |
| Messages fetched recently | The account is live and the fetch path works | That the messages were processed — a refusal holds work without dropping it |
| The read position moving | Work is progressing | That nothing was skipped, unless the position only advances on success |
| A send accepted by the provider | Outbound works from this mailbox | That the mailbox is sending as the right identity |
| Write-back succeeding | Labelling and read-marking work | Anything about the reply — a write-back failure never blocks it |
| The row appearing in the list | It is stamped with a workspace | That it is the only row for that address, if the uniqueness check reads the same scope |
The last line is the one that has actually bitten. A mailbox row stamped with an empty workspace id is invisible to every list and openable by id, so two connected identities can be absent from the Mailboxes screen with no warning at all — covered in invisible, not missing.
The quiet mailbox#
A mailbox that authenticates and returns nothing is the case a boolean cannot describe. It is not an error — nothing failed — and it is not health either, because an inbox a business depends on producing no mail for a week is information. It is recorded as a verdict so a person can decide which of the ordinary explanations applies.
- A rule at the provider files mail into a folder the connection does not read.
- Forwarding was set up and the mail now lands somewhere else.
- Nobody writes to that address any more, which is a business fact rather than a fault.
- The account is new and has genuinely received nothing yet.
- The read position advanced past everything, which is the failure the cursor rule exists to prevent.
Distinguishing them takes one comparison: what the provider's own view shows for the same window, against what the canonical thread list holds. That comparison is the fastest audit for mail exactly as it is for calls.
The setter that keeps a mailbox alive#
One implementation detail is worth publishing because it is the kind of thing that produces a healthy mailbox which quietly dies later. Mailbox rows present transport and config, which is all the provider factory reads. config is a real setter rather than a computed, read-only property — because the OAuth layer rebuilds the whole dictionary when it refreshes tokens and assigns it back.
A read-only property there would accept the assignment silently in some framings and drop it in others, and the symptom would be a mailbox that works for the lifetime of one access token and then stops, with a credential error that looks like the provider's fault. The defect would appear hours after the change that caused it, on a mailbox nobody touched.
What health checking will not tell you#
- Whether the mailbox is the right one for the job. A role and a signature are configuration, not health, and a mailbox sending as the wrong identity is perfectly healthy and wrong.
- Whether replies are good. Health is transport; quality is the engine's business and the approval queue's.
- How quickly a fault will be noticed. There is no published detection-time figure for a mailbox going quiet: UNKNOWN. What exists is the verdict, surfaced with the rest of a person's operational queue.
- Whether a provider outage is upstream. The verdict says what was observed from here; the provider's own status is a separate source and should be read as one.
Questions#
The mailbox says connected and nothing is happening. Where do I look first?
At the refusals, then at the provider. A spent daily allowance holds work rather than dropping it and shows the refusal in Needs You; if there is no refusal, compare the provider's own view of the last day with the conversation list. A quiet mailbox and a stuck one look identical from the connection status alone.
Is a quiet mailbox something to fix?
Usually not. It is a signal that the account is authenticating and returning nothing, which is correct for an address nobody writes to. It is worth investigating when the address is one customers actually use, because then the explanation is a rule, a forward or a read position rather than a lull.
A label did not get applied. Was the reply sent?
Those are separate operations and the second never blocks the first. Marking read and labelling in Gmail are write-backs; a failure there leaves the reply exactly as it was, and the send's own evidence is the provider's acknowledgement.