Short answer: ElevenLabs does not send a real-time “call failed” webhook while a call is in progress. The only conversation webhooks are post-call, delivered after the call ends and analysis completes.
What you can do
Post-call failure notification: Enable the post_call_transcription webhook and check data.status in the payload. Status values include failed (same schema as the GET Conversation response). This is sent after the call finishes. (elevenlabs.io)
Real-time monitoring during the call: Use the Agent WebSocket. It’s the only real-time channel (server-to-client events like transcripts, audio, etc.). You can detect disconnects/errors client-side and notify your own systems immediately. There is no built-in “failed” webhook event type. (elevenlabs.io)
Polling for status: If you need server-side detection without a client connection, poll GET /v1/convai/conversations/:conversation_id until status becomes failed or done. You can also list conversations and filter by call_successful=failure for reporting. (elevenlabs.io)
Important details
Supported webhook event types currently include post_call_transcription (call finished) and a few voice-removal events—there is no separate in-call failure webhook type. (elevenlabs.io)
Post-call webhooks can be HMAC-signed; repeated delivery failures are auto-disabled, and HIPAA-enabled webhooks are not retried. (elevenlabs.io)
Some failures occur before a conversation is created (e.g., missing required dynamic variables). In such cases there may be no transcript/webhook; the reason appears in Call History in the dashboard. (help.elevenlabs.io)
Bottom line: For immediate (“real-time”) failure handling, keep the WebSocket open and trigger your own webhook on error/close. For authoritative outcome (including failures) after a call ends, rely on the post_call_transcription webhook’s data.status or poll the Conversations API. (elevenlabs.io)
high hull
hard wedge