Summary
On 2026-07-14, both squad-handoff calls on our org experienced 12.6–16.3s of caller-facing silence during the handoff. Your own call log attributes the time to an opaque gap between call.handoffInitiated and call.handoffCompleted — 13.4s with zero intervening log events on the worst call. status.vapi.ai showed Operational all day. We'd like attribution, and answers on whether the ~3.5s baseline handoff cost is reducible.
- Org:
9964f993-8fb1-44a7-a6a2-4d9be92be414
- Worst call:
019f6046-3563-7000-8015-932d1a0d0b19 (2026-07-14, ~10:57 UTC)
- Same-day second call, also elevated (12.6s):
019f6034-c057-7aa2-bf6e-91c62902e707
- Earlier outlier (10.98s, 2026-07-08):
019f4188-bcfa-7556-b727-508b5e1c6758
Verified timeline (from artifact.presignedLogUrl of the worst call — your log, not our inference)
| t (rel) |
event |
| +14.7s |
caller stops speaking; endpointing 485ms |
| +14.8s |
LLM request (azure gpt-4.1-mini) — first token in 876ms (7,376 prompt tokens) |
| +15.634s |
native handoff tool starts; completes in 2ms (toolType: handoff) |
| +15.638s |
call.handoffInitiated |
| +29.051s |
call.handoffCompleted — 13.4s later, zero log events in between |
| +29.1s |
Deepgram/ElevenLabs teardown + rebuild, call.assistantStarted |
| +29.15s |
destination assistant LLM request (gpt-4.1) — first token 1,051ms (15,602 prompt tokens) |
| +30.7s |
bot audio starts (pipeline.botSpeechStarted) |
Every event in the log is eventStatus: success — no errors, no retries. STT/TTS/transport were all normal (626/504/20–50ms).
A metrics bug (or at least a misattribution) worth flagging
artifact.performanceMetrics.turnLatencies reports this turn as modelLatency: 15372. The raw log shows actual model latency was 876ms + 1,352ms — the metric lumps the entire handoff orchestration wait into the model bucket, which sent our debugging in the wrong direction initially. Attributing handoff wait as its own component would make this class of issue self-evident from the dashboard.
Baseline context
Across 62 squad handoffs on this org (2026-05-22 → 2026-07-10), handoffInitiated → first destination-assistant speech has a consistent ~3.5s floor (3.0–5.5s band), independent of the outliers above.
Questions
- What work happens inside
handoffInitiated → handoffCompleted, and what caused 13.4s / 12.6s on 2026-07-14 (both calls that day — not a one-off)?
- Was there unpublished platform degradation on 2026-07-14 and/or 2026-07-08 affecting the call path? The status page shows Operational for both dates.
- Is the ~3.5s handoff floor expected for server-side transient squads? Is any of it configuration-sensitive on our side (e.g. assistant prompt size, destination
firstMessageMode), or is it fixed platform cost?
- Could
performanceMetrics report handoff orchestration as a separate latency component instead of folding it into modelLatency?
Happy to provide anything else needed — the full log line set for the affected calls is retained on our side.
Summary
On 2026-07-14, both squad-handoff calls on our org experienced 12.6–16.3s of caller-facing silence during the handoff. Your own call log attributes the time to an opaque gap between
call.handoffInitiatedandcall.handoffCompleted— 13.4s with zero intervening log events on the worst call. status.vapi.ai showed Operational all day. We'd like attribution, and answers on whether the ~3.5s baseline handoff cost is reducible.9964f993-8fb1-44a7-a6a2-4d9be92be414019f6046-3563-7000-8015-932d1a0d0b19(2026-07-14, ~10:57 UTC)019f6034-c057-7aa2-bf6e-91c62902e707019f4188-bcfa-7556-b727-508b5e1c6758Verified timeline (from
artifact.presignedLogUrlof the worst call — your log, not our inference)toolType: handoff)call.handoffInitiatedcall.handoffCompleted— 13.4s later, zero log events in betweencall.assistantStartedpipeline.botSpeechStarted)Every event in the log is
eventStatus: success— no errors, no retries. STT/TTS/transport were all normal (626/504/20–50ms).A metrics bug (or at least a misattribution) worth flagging
artifact.performanceMetrics.turnLatenciesreports this turn asmodelLatency: 15372. The raw log shows actual model latency was 876ms + 1,352ms — the metric lumps the entire handoff orchestration wait into the model bucket, which sent our debugging in the wrong direction initially. Attributing handoff wait as its own component would make this class of issue self-evident from the dashboard.Baseline context
Across 62 squad handoffs on this org (2026-05-22 → 2026-07-10),
handoffInitiated → first destination-assistant speechhas a consistent ~3.5s floor (3.0–5.5s band), independent of the outliers above.Questions
handoffInitiated → handoffCompleted, and what caused 13.4s / 12.6s on 2026-07-14 (both calls that day — not a one-off)?firstMessageMode), or is it fixed platform cost?performanceMetricsreport handoff orchestration as a separate latency component instead of folding it intomodelLatency?Happy to provide anything else needed — the full log line set for the affected calls is retained on our side.