# Mail is in the provider but not in Connect

Check four things in this order: the daily allowance, the read cursor, whether the sync ran, and whether the bridge copied what the sync fetched. Each one produces the same symptom — a message at the provider and nothing on Conversations — and each has a different remedy, so the order is what saves the time.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/inbox, #/mailboxes, #/needs-you, #/billing
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/mail-not-arriving/

## What the symptom looks like

You can see the message in Gmail or in the mail server's own interface. Conversations does not have it. The mailbox row may look entirely healthy, because a green verdict describes the credential rather than the mail — that is why 'connected' is not a useful answer to this question.

> **Careful** Do not reconnect the mailbox as a first move. Three of the four causes below are unaffected by reconnecting, and the fourth is visible before you touch anything.

## The four checks, in order

| Check | What you see | What changes | What can fail |
|---|---|---|---|
| 1. The allowance | A refusal in Needs You; Plan and Usage shows the day spent | Nothing — work is held rather than dropped | Reading a held state as a lost message; it resumes at the reset |
| 2. The cursor | The last-sync time and how far back processing reached | Nothing while you look | Assuming the cursor jumped ahead — it does not advance on a refusal, by design |
| 3. The sync | The last-sync time moving after a manual Sync | New rows in the provider tables | A credential that fails, which is [the mailbox disconnected](/docs/troubleshooting/mailbox-disconnected/) |
| 4. The bridge | Whether the fetched message reached Conversations | Canonical threads and messages | A fetch that ran while the copy did not — the mailbox row looks identical either way |

The order is not arbitrary. Checks one and two need no action at all and explain most cases; check three is a single button; check four is the only one that needs a look at the conversation itself. Working the other way round means reconnecting a mailbox that was never broken.

## The diagnosis, stage by stage

1. Trigger — somebody reports a message that is at the provider and not in Connect.
2. External event — the message itself, which is intact and untouched throughout.
3. Authentication and workspace resolution — confirm which mailbox in which workspace should have fetched it; a second workspace's mailbox is a different question.
4. Ingest — press Sync and watch whether the last-sync time moves.
5. Canonical record — look for the thread on Conversations rather than for the message: a split thread hides a message in plain sight.
6. Classification — decide which of the four causes fits; each produces the same visible symptom.
7. Knowledge, memory and rules — a `block:email` directive stops a reply, never a fetch, so it is not a cause of missing mail.
8. Autonomy and approval — autonomy stops replies too, not arrivals; if the message is on Conversations and nothing was answered, this is a different page.
9. Action — clear the actual cause: wait for the reset, reconnect, or report the bridge failure.
10. Result — the message appears on Conversations, having been fetched from the cursor that never moved past it.
11. Relationship, timeline and memory — the person's timeline fills in the gap in order once the backlog drains.
12. Audit, usage and Needs You — the refusal, if that was the cause, is already recorded as a decision.

## What Connect did complete

- Nothing was deleted or altered at the provider. The message is where it was.
- The read cursor is still behind the missing message, which is what guarantees it will be fetched rather than skipped.
- Every message that did arrive is complete — the bridge writes a message or it does not, and there is no half-copied record.
- Where the allowance refused the work, the refusal is recorded and visible in Needs You rather than silent.

## What Connect did not complete

- The message was not bridged into the canonical tables, so no thread, no triage, no draft and no reply exist for it.
- No person or company was resolved from it, so it is absent from Customer 360 and from the timeline until it arrives.
- Nothing was answered. If somebody is waiting on a reply, they are waiting on no reply rather than a slow one.
- No follow-up was created from anything the message contains.

## What you can do, and when to escalate

1. Look in Needs You first.
   - Result: An allowance refusal is stated there, and it explains the whole symptom without any further work.
2. Press Sync on the mailbox and watch the time move.
   - Result: That separates a credential failure from everything else in one action.
3. Search Conversations for the sender rather than the subject.
   - Result: A message that threaded into an existing conversation is easy to miss when you are looking for a new one.
4. Check whether the mail is in a folder the mailbox does not read.
   - Result: For an IMAP mailbox this is a common and unglamorous cause.

An administrator can confirm the plan's allowance and its reset, check whether a rule at the provider is filing the mail somewhere the mailbox does not read, and confirm the mailbox is not one of a duplicated pair where the other row holds the message. Escalate when the sync runs, the allowance is not spent, and a message you can name is still absent from Conversations — that is the bridge, and it is the one cause a person cannot clear from a screen.

## Questions

### Could the message have been skipped permanently?

Not by an allowance refusal: the cursor deliberately does not advance on a refusal, precisely so nothing is skipped. That rule exists because advancing it would lose mail with no error anywhere.

### The message is on Conversations but nothing was drafted. Same problem?

No. Arrival and reply are separate stages. If the message is there, look at autonomy, directives and the allowance for replies — [the draft is still waiting](/docs/troubleshooting/draft-never-sent/) is the page for that.

### Does a large backlog arrive all at once?

It drains as the syncs run and within the day's allowance. A backlog that exceeds the allowance continues the next day rather than being abandoned.

## Related

- [Syncing an inbox](https://connectbyjbrh.com/docs/email/inbox-sync/)
- [Inbound email, end to end](https://connectbyjbrh.com/docs/workflows/inbound-email/)
- [Hitting the daily allowance, end to end](https://connectbyjbrh.com/docs/workflows/quota-refusal/)
- [IMAP UID and cursor lifecycle](https://connectbyjbrh.com/docs/email/imap-cursor/)
- [Gmail history sync](https://connectbyjbrh.com/docs/email/gmail-history-sync/)
- [The mailbox disconnected](https://connectbyjbrh.com/docs/troubleshooting/mailbox-disconnected/)
- [How a mail cursor loses messages, and how to stop it](https://connectbyjbrh.com/research/cursor-loss/)

## What this page is based on

- Connect source pack — channels, §1: the two mail models, the bridge, the allowance and the cursor (`docs-source/sources/CHANNELS.md`)
- Connect source pack — architecture: canonical records and what the engine reads (`docs-source/sources/GENERAL.md` §3)
- Connect capability registry (`docs-source/facts.py`) — `gmail_history_sync`, `imap_smtp`, `daily_quota_refusal`