No voice worker is available
No worker has checked in recently, so the realtime engine has nothing to hand a call to. New calls are refused before a record exists, with a retryable word, and the line reports the worker as the thing that is missing. It usually clears by itself within a deploy cycle; when it does not, it is a process that stopped, a fleet with no capacity, or a door with no token.
What it looks like#
From the caller's side: the number rings and nothing answers, or the call connects and drops immediately. From inside the workspace: calls are refused as not ready, and line health names an absent worker rather than a vague fault.
There was a version of this that was worse, and it is worth knowing because it shapes what the screen tells you now. An inbound call could reach nothing at all while the Phone screen still said the line was ready — the line was configured correctly, and readiness was being read from configuration rather than from a live process. Worker check-in is now one of the four things line health names separately, each of which can drain on its own.
What it means#
The realtime engine does not answer calls itself. A dispatch rule spawns a worker on the call's room, and that worker holds the model session. If no worker has reported in for 90 seconds, admission control refuses the call before any record is created. That ordering is deliberate: a refusal leaves no half-written call to reconcile later, and the word it refuses with is one the drain knows to retry.
Causes, most likely first#
- A deploy is in progress. Workers drain for three minutes so calls in flight can finish, and the service allows longer than that before stopping them. During the window, new calls are refused rather than accepted into a process that is about to exit.
- Every live worker is busy. Admission refuses when all of them are over the busy-load threshold, which is the same number the worker gives the room service, so the two cannot disagree about what busy means.
- The process stopped and did not restart. The heartbeat record forgets a process not seen for an hour, so a long-dead worker eventually disappears from the fleet rather than lingering as a phantom.
- The worker's door has no token. The endpoint the worker posts to is loopback-only and answers 503 when its token is unset. It is never open, so an unconfigured deployment fails closed rather than quietly accepting anything.
- The workspace is on the realtime engine but nothing was deployed for it. Setting the engine does not start a fleet.
What Connect completed#
- Refused the call cleanly, before any record was created, with a word that means "try again" rather than "this failed".
- Reported the absent worker as a distinct line-health condition, separate from capacity, from calls that never rang, and from sessions the model refused.
- Kept every other channel running. This condition is specific to the realtime voice path.
- Left the queue intact: a follow-up whose call was refused is still due, and is retried.
What Connect did not complete#
- The call was not answered. Nobody spoke to the caller, and no greeting was played.
- There is no call record, no transcript, no summary and no lead, because the refusal happened before the record.
- Nothing was charged, since no session existed.
- A caller who dialled during the window was not called back automatically — an inbound call that is refused is not a commitment Connect made.
What you can do#
Look at the line's health rather than its configuration.
Result The four conditions are named separately, so you learn whether this is an absent worker or a full fleet without guessing.
Wait one drain cycle — about three minutes — if a release has just gone out.
Result Refused calls of this kind are retryable, and queued work is picked up again by itself.
Place one test call.
Result A call that now produces a record is the only evidence that matters. A screen returning to a healthy state is not.
If it persists, tell an administrator that calls are being refused as not ready, and roughly when it started.
Result Those two facts separate a deploy window from a stopped fleet immediately.
What an administrator can do#
- Confirm workers are running and reporting; a fleet that exists but does not check in is the same as no fleet.
- Confirm the worker's token is set, since without it the door refuses the worker itself.
- Check whether the busy threshold is being hit rather than assuming absence — the recovery differs completely.
- Check that the drain window is not shorter than the service's own stop timeout, or a release will kill calls it should have let finish.
When to escalate#
Escalate when refusals continue past two drain cycles with no release in progress, or when calls are refused while the fleet reports capacity — the second is a disagreement between admission control and the workers, and it will not resolve by waiting. Bring the time it started and whether any other channel is affected; if mail and messages are fine, the problem is the voice fleet and nothing else.
Questions#
Why is the caller refused instead of being put on hold?
Because there is nothing to hold them for. Holding a caller against a fleet that may not return produces silence and then a drop, which is a worse experience than a line that does not answer, and it creates a record of a conversation that never happened.
Does this affect calls already in progress?
No. Calls being held by a running worker continue, and a deploy deliberately drains rather than cutting them. This condition is about admitting new calls.
Will my due follow-ups be lost?
No. The refusal is retryable, so a follow-up whose call could not be placed stays due and is attempted again, until it passes the late cut-off and becomes a decision for a person.