Ordered by frequency, not severity. Every check below names the screen to look at, because “it doesn’t work” is almost always one of four screens disagreeing with each other.
1. The number answers, but it isn’t your agent
The most common report, and the hardest to spot, because the phone call works. A connected number answers before anything is bound to it — a test agent picks up and sounds fine.
The check: ring the number and listen for your First thing your agent says. Hearing anything else means the number is not bound to your agent.
The fix: on /phone-numbers, the number should read ”… answers this channel” with your agent’s name. On /agents, the Deployment section should say Deployed to … rather than Not deployed or No voice channel. Fix whichever is wrong.
2. The mic test works and the phone doesn’t
These test different things, and passing the first proves nothing about the second. /agents says so outright: “WebRTC works for browser testing. Phone routes need a number.”
Start mic test exercises the agent. It does not exercise the number, the binding or the carrier. If the mic test is fine and calls are not, the problem is in the phone path, so go back to check 1.
3. The agent answers but doesn’t know anything
Not a fault. An agent with no knowledge attached answers correctly and unhelpfully.
The check: /agents/knowledge. If it is empty, that is your answer — “Create an agent first, then add knowledge to ground it.”
Add hours, prices, services and location, then re-run the mic test. This is the single highest-return fix on the list and it is not a bug report.
4. The call connects and then fails
Look at /conversations and find the call. The outcome tells you which half broke:
| What you see | What it means |
|---|---|
| Missed / No answer | Never reached the agent |
| Connected | Reached the agent and ran |
| Cut short | ”Connected, but the caller hung up before the agent finished.” |
| Failed | The call itself failed |
The Call timeline shows the phases — Connecting, Ringing, LIVE, Wrapping up — so you can see how far it got before stopping.
A run of Failed right after a carrier change usually means the carrier rejected the call: “Carrier didn’t accept the call — please retry in a moment.” Check the Dial format on the number — a carrier expecting national format rejects E.164, and the configuration saved cleanly.
5. It works but nothing is recorded
The calls happen, and afterwards there is nothing structured to look at.
The check: /dialog-insights. An insight showing Not attached never runs — “This insight never runs until you attach it to an agent or campaign.” Saving and attaching are separate actions.
Also check the field itself: “A Dialog Insight with no fields never produces a result.”
6. The voice changed by itself
It did not, but a pipeline change will do it. Realtime pipelines carry their own voices and standard uses your TTS provider’s, so switching Pipeline silently leaves you picking from a list that does not contain what you had. See voice pipelines.
7. It stopped working after you paused something
Pausing or archiving an agent stops it answering and stops it calling. If a campaign using that agent is running, it drains with every remaining call skipped and labelled rather than dialling on behalf of an agent you believe is off.
If none of these
Ring the number from a phone that has never called it, and watch /conversations while you do. If no conversation appears at all, nothing reached us and the problem is upstream of Octo — the number, its routing, or the carrier.