Inbox health and rotation
Two separate calculations sit behind sending: a health score shown on each inbox card, and a rotation calculation that decides which connected inbox has capacity for the next send.
On this page
Health score
Every connected inbox gets a 0–100 score, fully recomputed from live send-job data every time the Inboxes page loads — nothing is cached or read from a stored column. ERROR and DISCONNECTED inboxes are pinned to a flat score of 10 regardless of anything else. Otherwise the score starts at 100 and deducts:
| Factor | Deduction |
|---|---|
| Failure rate over a rolling 30-day window (minimum 20 sends in that window) | up to -40 (failure rate × 600, rounded, capped at 40) |
| Today's sends exceed 90% of the daily limit | -10 |
The final score never drops below 0.
The 30-day window is further bounded by the inbox's last genuine reconnect — old failures from before a reconnect don't drag the score down forever. Below 20 sends in that window, the failure-rate deduction doesn't apply at all, so a brand-new or lightly-used inbox starts clean rather than being penalized on too little data.
Because the failure penalty caps at 40, a failure rate of roughly 6.6% or higher produces the same -40 deduction as a far worse one — a connected inbox scoring on failure rate alone bottoms out at 60, or 50 once the capacity deduction also applies.
An OAuth access token nearing or past its own expiry doesn't affect the score — tokens roll over automatically and self-heal on the next send. The signal for a connection that genuinely needs attention is the ERROR status, set only when a token refresh actually fails, and it's already captured by the flat-10 pin above.
92 · Healthy
Score ≥ 80
68 · Degraded
Score ≥ 60
45 · At risk
Score ≥ 40
10 · Blocked
Below 40, or Error/Disconnected
A Disconnected inbox shows Unavailable in place of the health chip, both on its card and in its detail slide-over — there's no score displayed while it's out of rotation entirely.
The slide-over's own Placement & reputation section is a different number entirely — the percentage of sends that actually landed in the inbox over the last 30 days, sourced from warmup placement testing. It's a useful companion signal, but it isn't a factor in the 0–100 health score below; a high placement rate doesn't offset a high failure rate, and vice versa.
Capacity and remaining sends
For each connected inbox, remaining capacity for today is:
remaining = dailyLimit - sentToday - reservedToday
reservedToday counts that inbox's send jobs already created today with status PENDING or SENT — so capacity accounts for sends that are queued but not yet dispatched, not just ones that have already gone out. The daily limit and counter reset automatically at UTC midnight.
Rotation today
When a campaign needs to pick a sending inbox, ForgeSend looks at every CONNECTED inbox in the workspace (narrowed to the campaign's sender pool if one is set — see Sender pool) and includes any inbox with remaining > 0. Capacity is checked continuously at dispatch time, not once when the campaign launches.
On workspaces with health-weighted rotation turned on, that pool is filtered a second time by health score before any new lead is assigned — see Automatic exclusion from rotation below.
Within that eligible pool, ForgeSend also automatically prefers a same-provider inbox for the recipient. A lead whose own address is classified Google is routed to a connected, eligible Google inbox if one exists in the pool; a Microsoft-classified lead is routed to a connected, eligible Microsoft inbox the same way. If no inbox on the recipient's own provider is available, ForgeSend prefers whichever other native provider — Google or Microsoft — does have one, ahead of a generic or self-hosted inbox. Only when neither native provider has an eligible inbox in the pool does plain capacity-based rotation, as described above, choose across the whole pool.
Provider matching only ever changes which eligible inbox is chosen — it never pauses, delays, or skips a send. When a same-provider (or other-native-provider) inbox is available, it's simply preferred automatically; otherwise sending proceeds exactly as the capacity-based rotation above already describes.
Automatic exclusion from rotation
An inbox is pulled out of new-lead rotation automatically, by its own health score — no manual action, and nothing to do with any individual lead.
The cutoff is 70. When health-weighted rotation is enabled for the workspace:
| Health score | New-lead rotation |
|---|---|
| 70 or above | Eligible |
| Below 70 | Excluded — reason: health score below cutoff |
Because ERROR and DISCONNECTED inboxes are pinned to a flat score of 10, a broken or disconnected inbox is always below the cutoff and always excluded. A connected inbox crosses the cutoff on its own send record: a failure rate above roughly 5.1% over the last 30 days (with at least 20 sends in that window) is enough on its own to drop a 100-point inbox below 70.
The cutoff is 70, but the health chips above change colour at 80, 60 and 40 — they are display bands, not the rotation rule, and the cutoff deliberately cuts through the middle of the amber Degraded band. An inbox showing 68 · Degraded is below the cutoff and excluded; one showing 72 · Degraded is above it and still sending. Read the number, not the colour, when you want to know whether an inbox is still picking up leads.
This filter is controlled by a workspace-level feature flag. When health-weighted rotation is off, every connected inbox stays eligible regardless of its score — a low score is then purely an on-screen warning and changes nothing about which inbox sends. Capacity is always enforced either way.
This is an inbox-level mechanism: it removes one mailbox from the sending pool, and every campaign in the workspace that could have used that inbox is affected. It is completely separate from lead-level pausing, where a single contact's sequence stops because that contact replied — see Auto-pause and bounce handling. Neither one triggers the other.
How this differs from Deliverability
The Deliverability page's inbox readiness table uses its own PASS / WARNING / BLOCKED verdict per inbox, built from connection status, capacity, and token health as launch-readiness signals. The Inboxes page's 0–100 health score is a different calculation, built for ongoing send-quality monitoring rather than a one-time launch check. They're related — a disconnected or token-expired inbox scores badly on both — but they are not the same number, and a "Healthy" inbox here doesn't automatically mean every Deliverability check for it is a PASS.
The AI Account Analyst's reassign sender inboxes guided action reads this same inbox data to propose a replacement pool — always previewed and confirmed by you, never applied automatically outside of Launch Guardian's one specific case (an inbox removed from the workspace entirely).