Every line is busy
Every live worker is over the busy threshold, so admission refuses new calls rather than accepting them into a process that cannot hold them. Capacity is computed from what the workers report — one-minute load per core and the calls they are holding — and the same threshold is given to the room service, so admission and the fleet cannot disagree about what busy means.
What it looks like#
Inbound calls are not answered during the busy period and callers meet the carrier's own handling of an unanswered call. Outbound work — a due call-back, a scheduled call — is refused in a way that means "try again", and the drain picks it up shortly afterwards. Line health names capacity specifically, rather than reporting a general fault.
The pattern is bursty: refusals cluster, then stop. A steady refusal rate across a quiet period is a different problem, most often an absent worker rather than a busy one.
How capacity is computed#
Not from a call count. Each worker reports its one-minute load average per core with every heartbeat, alongside the calls it currently holds, and admission refuses when every live worker is over the busy threshold of 0.85. That figure is also what each worker gives the room service as its own load threshold, so admission control and the dispatcher are working from the same number rather than two numbers that drift apart.
| Input | Where it comes from | How it is read | Failure mode it prevents |
|---|---|---|---|
| One-minute load per core | Each worker's heartbeat | Compared against the busy threshold | Accepting a call into a process that cannot answer it in time |
| Calls held | Each worker's heartbeat | Reported alongside load | A fleet that looks idle by load while holding long calls |
| No load reported | A worker that sends none | Read as free | Refusing every call because an old worker went quiet, which would be worse than the saturation it guards against |
| Live workers | Recent check-ins | Only live workers count | Counting a stopped process as capacity |
Causes, most likely first#
- A genuine burst. More simultaneous calls than the fleet was sized for, usually predictable — a campaign, an outage elsewhere, a Monday morning.
- A deploy shrinking the fleet temporarily. Draining workers stop accepting new calls while finishing the ones they hold, so effective capacity dips before it recovers.
- Long calls holding processes. The product ceiling is 30 minutes per call; a handful of long conversations occupies capacity that short ones would have released.
- An undersized fleet. If refusals recur at the same hour each day, this is not a burst, it is the size of the deployment.
- A worker degraded rather than absent. A process that is up but overloaded contributes to saturation while still appearing in the fleet.
What Connect completed#
- Refused new calls before creating any record, so there is no half-written call to reconcile.
- Kept every call already in progress running normally — capacity refusal never interrupts a live conversation.
- Marked outbound refusals as retryable, so due work returns rather than being lost.
- Reported capacity as its own line-health condition, distinct from an absent worker.
What Connect did not complete#
- Inbound callers during the window were not answered, and no record of their attempt exists in the workspace — the carrier's log is the only place they appear.
- No queue was formed. Callers were not held waiting for a slot.
- No call-back was scheduled for a refused inbound caller; Connect made no promise to them and does not invent one.
- Nothing was charged for the refused calls, because no session started.
What you can do#
Check whether the refusals cluster in a window or run continuously.
Result Clustered is capacity; continuous in a quiet period is usually an absent worker instead.
Look at the carrier's log for calls that reached the application and were not answered.
Result That count is the real customer impact, and it is not visible in the workspace.
Move non-urgent outbound work out of the busy window.
Result Scheduled calls and due call-backs compete with live callers for the same fleet.
Report the window and the volume to an administrator.
Result Fleet sizing is a decision that needs the peak, not the average.
What an administrator can do#
- Add capacity for the peak rather than the mean; the gate refuses only when every live worker is over the threshold, so one spare worker changes the outcome.
- Check that draining workers are not the whole explanation before resizing anything.
- Confirm the threshold used by admission and the one given to the room service are still the same value — the point of that number is that there is only one of it.
- Look for workers that report no load at all. They are read as free by design, which is right for an occasional silence and wrong for a permanently mute process.
When to escalate#
Escalate when refusals happen while the fleet reports spare capacity — that is a disagreement between admission and the workers, and waiting will not fix it — or when a busy window costs enough unanswered calls that the fleet must be resized today rather than at the next release. Bring the window, the number of refused calls from the carrier's log, and the number of live workers during it.
Questions#
Why are callers not queued?
Because a queue against a saturated fleet is a caller listening to silence and then being dropped, and it produces call records for conversations that never happened. Refusing is worse for that caller and better for the record, and it keeps the failure visible rather than smearing it across held calls.
Does a busy fleet interrupt calls in progress?
No. Capacity is an admission decision. Calls already being held continue normally, and a deploy drains rather than cutting them.
Why does a worker that reports nothing count as free?
Because refusing every call on an old worker's silence would be worse than the saturation the gate guards against. It is a deliberate bias towards answering, and it is worth knowing when a process goes permanently quiet.