when voice is not spoken, what's the appropriate s...
# ask-ai
s
when voice is not spoken, what's the appropriate strategy to look into it? should I take a look at it through aws cloudwatch?
t
Thanks for reaching out, taeun. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — good question. You're asking whether AWS CloudWatch is the right place to look when a LiveKit agent session produces no spoken voice, and what the appropriate troubleshooting strategy should be. Short answer: CloudWatch can be helpful only if you’re already forwarding your agent runtime logs to it. The quickest and most direct places to inspect for a missing-voice problem are LiveKit’s agent runtime logs and Agent Observability in the LiveKit Cloud Dashboard. Recommended troubleshooting steps 1. Check agent runtime logs ◦ Use the LiveKit CLI or your logging sink to view the agent runtime logs. These logs record audio pipeline events, errors, and status messages that often reveal if the agent failed to play audio, encountered an encoding/decoding error, or had permission/IO problems. 1. Check Agent Observability (LiveKit Cloud Dashboard) ◦ Inspect session traces and logs for the specific session/room. Observability shows traces that help identify where audio stopped (e.g., at TTS generation, network, or playback). 1. If you forward logs to external systems (like CloudWatch) ◦ CloudWatch is fine to use if your agents are already configured to forward logs there. It won’t add extra LiveKit-specific diagnostic detail beyond whatever your agent runtime is emitting, but it does let you search, filter, and alert on log messages. 1. Narrow the cause by confirming: ◦ Is the TTS or audio source producing audio? (Check the TTS service or file before it reaches the agent.) ◦ Are there network errors or interruptions reported in the logs? ◦ Are there codec/format mismatches or playback errors reported? ◦ Are permissions or device errors preventing playback on the client side? 1. Collect useful identifiers for deeper debugging ◦ Session/room ID, agent ID, approximate timestamps, and any error messages shown in logs. Those let us pinpoint traces in Agent Observability or specific log lines in CloudWatch. If you’d like, tell me: • Whether you already forward agent logs to CloudWatch (yes/no). • The session/room ID and approximate time when the issue happened. • Any error lines you’ve seen in logs or the client console. I’ll guide you through the next steps based on what you find (or look up the relevant traces if you share those identifiers). Sources: Where to find your Agent Logs | LiveKit