Why does Vapi show endedReason: customer-did-not-give-microphone-permission?

This endedReason fires when the browser (in web-based Vapi integrations) cannot access the microphone. It is almost always a browser permissions issue rather than a Vapi configuration problem. The caller either denied microphone access when prompted, or the site is served over HTTP instead of HTTPS (microphone access requires a secure context in all modern browsers). Check that your domain is served over HTTPS and that your integration correctly triggers the browser permission prompt before initiating the Vapi session.

How do I debug Vapi function calling failures?

Function call failures in Vapi appear in the call object's messages array as a toolCallResult with a result field containing an error. The most common causes are: the function endpoint returns a non-2xx response (Vapi considers anything other than 200 a failure), the function takes longer than Vapi's configured function timeout (default 20 seconds), or the function returns a malformed JSON response that Vapi cannot parse. Check the toolCallResults in the Vapi call object first — the result field will contain the exact response your endpoint returned, which is usually enough to identify the bug.

Why is my Vapi agent silent sometimes?

Silence after a user speaks is almost always an LLM response latency issue, not an audio failure. Vapi uses endpointing to detect when the user has finished speaking — once endpointing fires, Vapi sends the conversation to the LLM and waits for a response. If the LLM takes longer than expected (typically over 1.5 seconds for streaming responses), the caller hears silence. Check your Vapi call object's latency breakdown by stage. If llmLatency is the outlier, the fix is a faster model (GPT-4o mini, Claude Haiku) or a shorter system prompt that reduces first-token latency.

Debugging Vapi Calls: The Complete Guide to Finding Root Causes Fast

The Vapi call lifecycle: what happens at each stage and what can fail

Understanding which stage of the Vapi call lifecycle produced the failure is the foundation of effective debugging. A Vapi call moves through five stages in sequence, and failures at each stage have distinct signatures.

Stage 1 — Connection: Vapi establishes the telephony connection (via Twilio or another provider), initialises the session, and loads the assistant configuration. Failures here appear as endedReason values like 'pipeline-error-openai-voice-failed' or 'error-vapifault'. If the call fails before the caller hears anything, the problem is in this stage.

Stage 2 — Conversation initiation: Vapi sends the first message from the assistant (the greeting). This requires the LLM to generate a response and the TTS engine to synthesise audio. Failures here produce silence on the caller's end with the call terminating shortly after. Look for endedReason: 'customer-ended-call' combined with a very short duration — the caller hung up because nothing happened.

Stage 3 — Active conversation: The call is live. The caller speaks, Vapi's STT processes the speech, the LLM generates a response, and TTS synthesises audio. Failures here produce dropped calls mid-conversation, silence after user utterances, or incorrect agent behaviour. This is the most complex stage to debug because failures can originate in the STT layer, the LLM layer, or the TTS layer.

Stage 4 — Function execution: If your agent uses tools (server-side functions that Vapi calls during the conversation), failures here cause the agent to stall or produce unexpected responses. Look for tool call results in the messages array.

Stage 5 — Transfer and termination: If the agent attempts to transfer the call to a human or another number, failures here cause the call to drop instead of transferring. Look for endedReason: 'transfer-failed' or 'dial-failed'.

Reading the Vapi call object — every field that matters

The Vapi call object is available from the Vapi API (GET /call/{id}) and is also delivered in the end-of-call-report webhook payload. It contains everything you need for initial diagnosis.

The status field tells you the final state: ended is normal termination, failed indicates a Vapi-level error before the call could complete.

The endedReason field is the most important field for debugging. Key values to know: customer-ended-call — the caller hung up normally; assistant-ended-call — your agent terminated the call intentionally (check your assistant's endCallPhrases or endCallFunctionEnabled); voicemail — the call reached a voicemail recording; silence-timed-out — no caller audio was detected within the configured silenceTimeoutSeconds; max-duration-exceeded — the call hit your maxDurationSeconds limit; pipeline-error-* — a provider-level error in the Vapi processing pipeline.

The latency object breaks down response time per stage. Look for llm, tts, and vapi fields — if llm is the outlier (above 1,500ms on streaming responses), the silence issue is LLM latency, not TTS.

The messages array contains the full conversation transcript including all tool call requests and their results. For function call debugging, look for toolCallResult message types — the result field contains exactly what your function endpoint returned.

The cost and costBreakdown fields show the per-stage cost attribution — useful for detecting unexpectedly expensive calls caused by runaway LLM response length or model selection.

The most common Vapi failure types and their diagnostic signatures

LLM timeout — the most common cause of silence after the user speaks. The caller speaks, Vapi's STT processes it correctly, but the LLM takes too long to generate a response. Signature: endedReason: silence-timed-out or customer-ended-call with a high llmLatency value in the latency breakdown. Fix: switch to a lower-latency model (gpt-4o-mini, claude-haiku-4-5) or shorten your system prompt to reduce first-token latency.

Endpointing misfires — the agent interrupts the caller mid-sentence because Vapi's endpointing algorithm detected a pause as a speaking endpoint. Signature: the messages array shows a user utterance that is cut off, followed by an agent response that does not match what the user was saying. The caller appears confused in subsequent turns. Fix: increase the endpointingConfig.onPunctuationSeconds and onNoPunctuationSeconds values in your assistant configuration to give the caller more silence before Vapi assumes they've finished speaking.

Tool call failure — your agent tried to call a server-side function and the function returned an error or timed out. Signature: a toolCallResult message in the array with a non-success result, often followed by the agent producing a confused or generic response. Fix: check the result field — it contains the exact response your endpoint returned. The most common causes are 4xx/5xx responses from your endpoint, function timeout (default 20s), and malformed JSON responses.

Transfer failure — the agent attempted to transfer the call but the transfer did not connect. Signature: endedReason: transfer-failed or dial-failed. Fix: verify the transfer destination number is correctly formatted (E.164 format required), that your Twilio number has permission to make outbound calls to that number, and that the transfer destination is not a voicemail-only line.

How to correlate Vapi calls with Twilio when running on Twilio infrastructure

When Vapi is configured to use Twilio as its telephony provider, every Vapi call corresponds to a Twilio Call SID. Finding this correlation is essential for root cause analysis on failures that span both layers — particularly for call drops, no-audio issues, and transfer failures that look different in each system.

The Twilio Call SID is available in the Vapi call object in the phoneCallProviderId field (for phone calls routed through Twilio). Use this SID to pull the full Twilio call record: GET /2010-04-01/Accounts/{AccountSid}/Calls/{CallSid}.json — this gives you the Twilio-side status, duration, direction, and any error codes that Twilio logged independently.

The critical cross-reference is timestamps. Vapi and Twilio timestamp the same events from different perspectives — Twilio timestamps when the telephony event fired at the carrier layer, Vapi timestamps when its processing pipeline received or generated the event. For silence-timeout failures, the Twilio call event log will show the exact moment the call terminated from the telephony side, which you can compare against the Vapi latency breakdown to identify which layer's timing caused the drop.

For transfer failures specifically: Twilio will log the outbound dial attempt to the transfer destination as a separate Call SID. Pull that SID and check its status — if it shows 'failed' or 'busy', the transfer destination itself is the problem, not the Vapi transfer configuration.

Debugging checklist: 15-minute incident triage for Vapi calls

This checklist is designed to get from 'something failed' to 'we know what failed and why' in under 15 minutes.

Minutes 1–3 — Pull the call object: GET /call/{id} from the Vapi API. Read endedReason first. If it's customer-ended-call, check call duration — under 10 seconds is suspicious, over 30 seconds with a normal conversation flow is probably a genuine hang-up. If it's pipeline-error-*, the problem is in Vapi's infrastructure. If it's silence-timed-out, check llmLatency.

Minutes 3–6 — Check the latency breakdown: if llmLatency is the outlier, the fix is model speed or prompt length. If ttsLatency is the outlier, check text length in the messages array. If vapi latency is the outlier, check Vapi's status page — this indicates a platform-level issue.

Minutes 6–10 — Read the messages array: reconstruct the conversation from the transcript. Check that user utterances are complete and correctly transcribed (endpointing issues show as truncated utterances). Check all toolCallResult entries — any non-success result is a function call failure that contributed to the incident.

Minutes 10–13 — Cross-reference with Twilio (if applicable): pull the Twilio Call SID from phoneCallProviderId. Check Twilio call status, duration, and any error codes. For transfers, pull the outbound dial SID.

Minutes 13–15 — Document the root cause hypothesis: write one sentence in the format 'The call failed because [component] [did what] at [timestamp] due to [cause].' If you cannot complete this sentence, you have not found root cause yet — go back to step 1 with a different failure type hypothesis.

Automating Vapi call forensics with Sherlock

The 15-minute triage above — pulling the Vapi call object, cross-referencing Twilio timestamps, classifying the failure type — adds up quickly at scale. For a team handling 200 Vapi calls per day with a 4% failure rate, that is 8 failures per day worth investigating. At 15 minutes each, that is 2 hours of daily debugging that does not ship anything.

Sherlock connects to Vapi and Twilio via OAuth and runs the triage automatically when a call failure matches a configured pattern. The case file it posts in Slack includes the endedReason classification, the latency breakdown by stage, the relevant messages from the conversation, and the cross-referenced Twilio call record — everything from the 15-minute checklist, in under 60 seconds.

The free tier (100 credits per workspace) covers the first 100 call investigations. To see what a Sherlock case file looks like for a Vapi failure, connect your stack at [usesherlock.ai](https://usesherlock.ai/?utm_source=blog&utm_medium=content&utm_campaign=vapi-debugging-guide).