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 -30 (failure rate × 600, capped) |
| Today's sends exceed 90% of the daily limit | -10 |
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.
An earlier version of this scoring function also deducted points for an OAuth access token nearing or past its own expiry. That deduction was deliberately removed — access tokens roll over automatically and self-heal on the next send, so it isn't evidence of a broken connection. The ERROR status check (set only when a refresh attempt actually fails) is the one reliable "needs reconnect" signal that's left, 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. This is capacity-based, not health-weighted — a Degraded or At risk inbox with sends left today is used exactly like a Healthy one; only a Blocked inbox (score below 40) can be excluded from picking up new leads, and only on workspaces where health-weighted rotation is turned on. Capacity itself is still checked continuously at dispatch time regardless of that setting.
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.
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).