All fields are required
When your voice AI spans five vendors, diagnosing a failure means correlating logs from five systems with no shared trace ID, timestamp format, or error taxonomy.
Trusted by 2,000+ companies
Twilio has a CallSid. Deepgram has a request_id. ElevenLabs has a generation_id. Correlating these requires custom mapping code that you build and maintain.
Twilio reports 'completed' for calls that ended normally. Your TTS provider reports a 422 for quota exhaustion. A 'successful' call in one dashboard can be a failed call for the caller.
A production deployment ran out of TTS characters mid-month. The orchestration layer swallowed the 422 error. Callers heard silence for three days before anyone noticed.
You can measure STT latency and TTS latency separately, but not the total time the caller waited. That measurement spans all five vendors plus your server.
from signalwire_agents import AgentBase
from signalwire_agents.core.function_result import SwaigFunctionResult
class SupportAgent(AgentBase):
def __init__(self):
super().__init__(name="Support Agent", route="/support")
self.prompt_add_section("Instructions",
body="You are a customer support agent. "
"Greet the caller and resolve their issue.")
self.add_language("English", "en-US", "rime.spore:mistv2")
@AgentBase.tool(name="check_order")
def check_order(self, order_id: str):
"""Check the status of a customer order.
Args:
order_id: The order ID to look up
"""
return SwaigFunctionResult(f"Order {order_id}: shipped, ETA April 2nd")
agent = SupportAgent()
agent.run()
| Error type | What it covers |
|---|---|
| STT errors | Transcription failures, confidence drops |
| TTS errors | Synthesis failures, quota exhaustion |
| LLM errors | Inference timeouts, token limits, rate limits |
| Tool errors | Tool function failures, webhook timeouts |
| Transfer errors | Failed transfers, destination unavailable |
| State errors | Variable conflicts, step transition failures |
| Media errors | Codec negotiation, audio quality degradation |
| Connection errors | Call setup, teardown, network issues |
| Timeout errors | End-of-speech, inactivity, session limits |
| Auth errors | Tool authentication, webhook signature failures |
Running out of TTS characters mid-month is not theoretical. It happened to multiple production deployments. Teams discovered they had been out of budget for days before noticing.
State transitions, tool calls, transfers, and barge-in events log with timestamps, causal triggers, and typed metadata. No manual instrumentation.
How long STT, LLM inference, TTS, and tool calls took. Measured at the source, not approximated from external API response times.
Not 'step changed from greeting to main' but 'step changed because the caller said I need help with billing, which matched the billing_inquiry transition.'
When the caller interrupted, how the AI responded, and whether the interruption was a real barge-in or a conversational acknowledgment.
If response time increases by 200ms over a week, the enriched log shows which component is responsible. Multi-vendor stacks require manual correlation across dashboards.
A gradual increase in STT confidence drops might indicate microphone quality issues or background noise patterns. SignalWire surfaces this as a trend in structured data.
If callers interrupt the AI more frequently on certain prompts, barge-in analytics reveal which parts of the conversation flow need tuning.
What percentage of transfers fail? Which destinations are unreachable? How often does context get lost? Single-stack observability answers these without custom instrumentation.
No. SignalWire provides the structured event data. You can export it to your existing monitoring stack (Datadog, Grafana, custom dashboards). The difference is that the data comes from one source with one schema.
Every error is classified into one of 10 types (STT, TTS, LLM, Tool, Transfer, State, Media, Connection, Timeout, Auth) with severity, cause, and timestamp. No ambiguity about which component failed.
A structured record of every event in a call: state transitions, tool calls, transfers, barge-in events, per-component latency, and errors. All in one timeline with causal links between events.
Yes. Because errors are typed and structured, you can alert on TTS quota errors, transfer failures, latency thresholds, or any combination. No regex parsing of unstructured logs.
The TTS error would appear immediately in the enriched call log as a typed TTS error with cause quota_exhausted. An alert on TTS errors would fire on the first affected call, not three days later.
Trusted by
Get one view of the entire call lifecycle, from PSTN ingress to AI processing to resolution.