Skip to main content

​
Troubleshooting: pool spread and anti-snowshoe alerts

Carriers score how your traffic spreads across the numbers behind a pool, not only the reputation of each number. Two extremes both hurt deliverability: push too much daily volume through too few numbers and each one hits the carrier’s per-number ceiling and gets throttled; spread modest volume across far more lightly-used numbers than it needs and the pool looks like a snowshoe operation — the abuse pattern of many low-volume numbers used to dodge per-number filtering — and carriers filter the whole set. The sender-pool deliverability autopilot keeps every active number inside a healthy daily-volume band and raises an alert when a pool drifts out of it. This page explains the two alerts, how to confirm what the autopilot saw, and the consolidations or capacity additions that clear them. The feature shipped 2026-07-10 — pools with no recent traffic are left alone, and auto-scaling only adds capacity, never removes it.

​
The two alerts

The alerts are complementary sides of the same band. A consolidate-pool alert means “too many numbers for the volume”; an auto-scale event means “too few for the volume.” Neither is an outage — both are the band working as designed.

​
Confirm before you act

Work the read path in this order:
  1. Open the pool in the dashboard under Messaging → Sender pools, or list pools with GET /api/v1/messaging/sender-pools. The member health view shows each member’s deliverability tier and rotation alerts.
  2. Read per-member health with GET /api/v1/messaging/sender-pools/{id}/health — the same signal the rotation scheduler acts on. Count members with near-zero daily volume on a thin pool, or members pinned at their daily ceiling on an overloaded one.
  3. Compare real volume against pool size. Pull the pool’s daily send totals from the delivery log or analytics and divide by the number of active members. A per-member average far under the carrier’s per-number ceiling is the thin-pool signature; a member hitting its ceiling daily is the overload signature.
  4. Preview the pick before changing anything with GET /api/v1/messaging/sender-pools/{id}/preview so you know the pool still resolves a sender for your destination after the change.

​
Fix paths

​
Consolidate a thin pool

A consolidate-pool alert clears when the pool stops looking like an evasion pattern:
  1. Identify the members with no recent traffic — the autopilot already excludes idle pools, so every member it flagged had some activity, but the tail is what inflates the spread.
  2. Move stale numbers out of the pool (or delete the pool and rebuild it around the few numbers that carry real volume). Do not delete numbers you still need inbound routing on — remove them from the pool, not from your inventory.
  3. Point any wiring that referenced the pool — a messaging service’s default pool, a country_sender_pools entry — at the right-sized pool. A stale pointer raises SENDER_POOL_NOT_FOUND on the next send.
Right-sized means every member carries a meaningful share of daily volume instead of dozens of members each taking a sliver.

​
Add warmed capacity to an overloaded pool

When volume genuinely outgrew the pool:
  1. Check whether the autopilot already added a warmed number you own — it does this automatically when one is available. The alert fires as a record of the action, and it stops firing once the spread is back in band.
  2. If you have no warmed spare number, acquire one and warm it before adding it — see number warming caps. A pool member passes through the same daily-cap ramp as a solo sender, so adding a cold number just moves the throttle.
  3. Split the destination traffic if one pool serves wildly different volume profiles — for example, a low-volume transactional flow and a high-volume campaign — instead of forcing one pool to cover both.

​
What not to do

  • Do not register more numbers to inflate a thin pool. Buying more senders spreads the same volume thinner, deepens the snowshoe signature, and is the exact pattern carriers filter. Consolidate first; add numbers only once volume justifies them.
  • Do not rotate through “fresh” numbers to evade the alert. Swapping under-used members for new low-volume ones resets the same pattern with a new coat of paint — carrier intelligence scores the pool’s behavior, not any single member.
  • Do not disable auto-scaling to stop the alerts. The alert tells you about a real carrier-side penalty. Muting the source keeps the penalty and loses the early warning.
  • Do not strip a number from the pool while a send targets it. Pull members between sends, or after the last campaign window, so in-flight messages keep their promised sender.

​
Escalation

Escalate to support when the alert persists after a solid fix attempt — a re-sized pool still flagged days later, or an auto-scale event that repeats every day with plenty of spare warmed numbers available. Include:
  1. The pool id and the alert text as it appeared, with a timestamp and timezone.
  2. The member list — pool size, and each member’s recent daily volume from the health read.
  3. What you changed — members removed, numbers added, or wiring repointed — and when.
With those three, support can pull the autopilot’s band evaluation and re-check the pool’s spread directly.
  • Sender pools — create pools, read member health, preview picks, and configure the volume band.
  • Number warming caps — the per-number daily ramp a new member passes through before it can carry pool volume.
  • Sender resolution and pool errors — SENDER_POOL_NOT_FOUND and friends, for when a consolidation moved a pointer without repointing it.
  • Sender and routing — how pools participate in sender resolution.