# Hitting the daily allowance, end to end

When the daily allowance is spent, work is held rather than dropped and the read cursor deliberately does not advance. Needs You shows the refusal, nothing is deleted, and processing resumes from exactly the message it stopped at. Advancing a cursor on a refusal is how a mail agent loses messages permanently, so the refusal is written to be lossless.

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

## The refusal, stage by stage

1. Trigger — a sync tick, a draft, or a send asks for capacity the day's allowance no longer has.
2. User or external event — none. Nothing the customer did caused this; the mail is still sitting at the provider, untouched.
3. Authentication and workspace resolution — the allowance belongs to the workspace, so it is read after the workspace is resolved and never before.
4. Ingest — the fetch may already have run in part; what it wrote stays written.
5. Canonical record — whatever was bridged before the refusal is a complete record. There is no half-message.
6. Classification — the refusal is identified by its own code rather than being reported as a provider failure, because it is a decision and not a fault.
7. Knowledge, memory and rules — untouched. A refusal changes no rule and forgets nothing.
8. Autonomy and approval — a held item keeps its autonomy state; a reply that was waiting for approval is still waiting for the same approval.
9. Action — nothing is sent, nothing is fetched, and — this is the part that matters — the read cursor is not moved.
10. Result — a refusal recorded against the work, with the reason available to a person rather than buried.
11. Relationship, timeline and memory — no relationship changes, because nothing happened to the person on the other end.
12. Audit, usage and Needs You — the refusal is a decision and is logged as one; Needs You shows it; usage on Plan and Usage explains why.

## Why the cursor does not move

A read cursor is a promise: everything before this point has been processed. Advance it past mail that was refused and the promise becomes a lie that nothing can detect — the next fetch asks the provider for mail after a point that was never read, the skipped messages are never asked for again, and no error is raised anywhere, because from the provider's point of view the conversation was entirely normal.

That is why the refusal deliberately leaves the cursor where it is. The cost is re-reading a handful of messages on the next tick; the alternative cost is a customer's message that no longer exists anywhere in the workspace and cannot be recovered, because nobody knows it was missed. Duplicated work is cheap and visible. Lost mail is neither.

| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Fetch refused | The last-sync time stops moving | Nothing; the cursor stays | Reading a frozen sync time as a broken mailbox rather than a spent allowance |
| Bridge partially done | Some conversations are newer than others | Only what was fully written | Nothing — a partial bridge is re-read from the unmoved cursor |
| Draft refused | No new drafts appear on threads | Nothing | Assuming the engine has stopped working |
| Send held | The approval stays in Needs You after you approve it | The approval is recorded; the send waits | Approving repeatedly, which does not add allowance |
| Follow-up due | The commitment waits rather than closing | Nothing is consumed | Reading a waiting commitment as a missed one |
| Reset | Work resumes on the next tick | The backlog is processed from where it stopped | Expecting an instant catch-up on a large backlog rather than a steady drain |

## What a person sees, and what to do

The refusal surfaces in Needs You rather than in a log, because it is a condition somebody may want to act on. Plan and Usage is where the arithmetic lives: what the allowance is, what has been used, and when it resets. The two screens answer different questions — one says work is waiting, the other says why.

1. Read the refusal in Needs You before changing anything.
   - Result: It names what was refused, which separates a spent allowance from a broken mailbox — they look identical from Conversations.
2. Check Plan and Usage for the reset.
   - Result: Work resumes by itself at the reset; nothing needs restarting.
3. If the day's mail regularly exceeds the day's allowance, change the plan rather than the workflow.
   - Result: Deferring mail every day is not a stable state — the backlog only clears if some day has spare capacity.
4. Verify afterwards that Conversations caught up rather than skipped.
   - Result: The oldest unprocessed message should have moved, not vanished; the cursor is what guarantees that.

> **Note** The Owner's workspace has no plan and no gates. A customer workspace is bounded by its plan's allowances. That is the only commercial difference between the two audiences: the feature set is identical and runs on the same implementation.

## Related failure modes worth separating

**A burst rather than a limit** — A large arrival is a different problem from a spent allowance; see [ingesting a burst of mail](/docs/workflows/burst-ingest/).
**A quiet mailbox** — Nothing is refused and nothing arrives, because nobody wrote. The last-sync time keeps moving, which is the signal that separates the two.
**A disconnected mailbox** — The credential failed. Needs You says so, and the cursor is again untouched — [the mailbox disconnected](/docs/troubleshooting/mailbox-disconnected/).
**A suppressed recipient** — One message refused rather than all work held. The reason is per recipient and is recorded against that send.

## Questions

### Is mail lost when the allowance runs out?

No. That is the single most important property of this refusal: work is held, not dropped, and the read cursor stays where it is so that nothing is skipped when processing resumes.

### Does approving a held reply during a refusal do anything?

It records the approval. The send waits for capacity and then goes without being approved again, so approving twice achieves nothing and approving once is not wasted.

### Why does the mailbox look broken instead of paused?

Because a frozen last-sync time is the same symptom as a failed credential. The refusal in Needs You is what distinguishes them, which is why it is surfaced there rather than left in a log.

## Related

- [The daily email allowance](https://connectbyjbrh.com/docs/email/daily-allowance/)
- [Syncing an inbox](https://connectbyjbrh.com/docs/email/inbox-sync/)
- [Inbound email, end to end](https://connectbyjbrh.com/docs/workflows/inbound-email/)
- [Large batches and bursts](https://connectbyjbrh.com/docs/email/burst-handling/)
- [Ingesting a burst of mail, end to end](https://connectbyjbrh.com/docs/workflows/burst-ingest/)
- [How a mail cursor loses messages, and how to stop it](https://connectbyjbrh.com/research/cursor-loss/)
- [Mail is in the provider but not in Connect](https://connectbyjbrh.com/docs/troubleshooting/mail-not-arriving/)

## What this page is based on

- Connect source pack — channels, §1: the allowance holds work rather than dropping it and does not advance the cursor (`docs-source/sources/CHANNELS.md`)
- Connect source pack — the two audiences: a customer is bounded by a plan, the Owner is not (`docs-source/sources/GENERAL.md` §1)
- Connect capability registry (`docs-source/facts.py`) — `daily_quota_refusal`, `billing_usage`