> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting: pool spread and anti-snowshoe alerts

> What the deliverability autopilot's pool-spread alerts mean — 'pool spread too thin' (snowshoe pattern) and 'volume outgrew the pool' — how to confirm them against your pool health reads, and the fix paths that restore a healthy spread.

# 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](/guides/sender-pools) 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

| Alert                                        | What the autopilot saw                                                                                                                                                                                                              | Fix class                         |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- |
| **Consolidate pool** (spread too thin)       | The pool has far more active numbers than its real volume justifies — the snowshoe pattern carriers filter. The autopilot flags the pool; it never removes numbers on its own, because trimming live sending capacity is your call. | Consolidate to a right-sized pool |
| **Pool outgrew its numbers** (auto-scale-up) | Daily volume outgrew the pool's members, so at least one number is running into the carrier's per-number daily ceiling. The autopilot already added a warmed, healthy number you own, when one was available.                       | Add warmed capacity, or re-route  |

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](/troubleshooting/sender-resolution-errors)
   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](/troubleshooting/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.

## Related references

* [Sender pools](/guides/sender-pools) — create pools, read member
  health, preview picks, and configure the volume band.
* [Number warming caps](/troubleshooting/number-warming-caps) — the
  per-number daily ramp a new member passes through before it can carry
  pool volume.
* [Sender resolution and pool errors](/troubleshooting/sender-resolution-errors) —
  `SENDER_POOL_NOT_FOUND` and friends, for when a consolidation moved
  a pointer without repointing it.
* [Sender and routing](/concepts/sender-and-routing) — how pools
  participate in sender resolution.