How to Export ElevenLabs Agent Metrics to Prometheus and Grafana for Realtime Avatars
Export ElevenLabs agent metrics to Prometheus and Grafana to monitor latency, errors, sessions, and avatar lag in realtime avatars.
Introduction
If you run ElevenLabs agents in production, the interesting question is rarely “is the agent up?” It is “is it responsive, are calls actually flowing, and are the user-facing sessions healthy enough to support a realtime avatar?” Once you attach a video face to the agent, slow synthesis, queueing, audio glitches, or session churn become visible to users much faster than they do in logs.
This post shows a practical way to export ElevenLabs agent metrics into Prometheus, visualize them in Grafana, and use those dashboards to catch realtime avatar issues before customers do. The goal is to give you a metrics pipeline you can apply to voice agents, WebRTC sessions, and avatar-rendering workflows without turning your app into a science project.
What you should measure for a realtime avatar stack
Prometheus is most useful when you expose metrics that correlate with user experience. For an ElevenLabs-backed voice agent with a synced avatar, the signal usually falls into four buckets:
Session volume — active sessions, starts, disconnects, reconnects.
Latency — time to first audio, first token, first visible frame, end-to-end response time.
Quality and failure rate — synthesis errors, transport errors, frame drops, canceled turns.
Resource pressure — queue depth, in-flight requests, concurrency limits, retry counts.
For realtime avatars, I would also track a few derived metrics, because they tell you more than raw counters:
Avatar render lag: time between the agent emitting speech and the avatar presenting the corresponding frame.
Turn completion ratio: completed turns divided by started turns.
Session survival: percentage of sessions that stay connected for a minimum duration.
Prometheus works well here because these are all either counters, gauges, or histograms. That means you can instrument them cheaply in-process, scrape them on an interval, and build alert rules around service behavior rather than logs.
Exporting metrics from your agent process
The simplest pattern is to keep a tiny metrics surface inside the agent service itself. You increment counters when an ElevenLabs request starts or fails, observe durations for synthesis and turn latency, and expose a /metrics endpoint for Prometheus to scrape.
In Python, the prometheus_client library gives you the basics. The exact metric names are up to you, but the shape should be stable and boring.
That gets you the export path, but not yet the context. You want the metrics to be specific enough that a dashboard can answer operational questions. For example, if a spike in tts_latency_seconds correlates with avatar frame delays, you now know the bottleneck is upstream of rendering rather than in the video pipeline.
A few practical rules help:
Use histograms for latency, not just averages. Percentiles matter much more than means.
Keep labels low-cardinality. Status, model, region, and tier are usually fine; session IDs are not.
Separate request failures from transport failures if you can. They imply different fixes.
Record turn-level metrics close to the agent event loop, not in a downstream analytics job.
Scraping with Prometheus and visualizing in Grafana
Once your service exposes /metrics, Prometheus just needs a scrape config. Here is a minimal example.
If your agent runs behind an orchestrator, put the exporter on the same network path as the process you actually care about. The reason is simple: metrics should reflect the service you operate, not a proxy layer that may hide the real latency source.
In Grafana, build panels that answer operational questions quickly:
Active sessions as a gauge over time.
Request rate and error rate for TTS and turn completion.
P50/P95/P99 latency for synthesis and end-to-end turn time.
Session duration distribution to catch disconnect patterns.
Useful PromQL examples:
For a realtime avatar system, I would add one panel that compares synthesis latency with avatar render lag on the same time axis. If the avatar is lagging while TTS stays flat, the problem is probably in frame generation, WebRTC transport, or the client render loop. If both climb together, the agent side is overloaded.
Gotchas that matter in production
Most metrics bugs in this kind of system are self-inflicted. The common ones are predictable:
High-cardinality labels are the fastest way to ruin a metrics system. Do not label by session ID, user ID, transcript text, or per-message identifiers. If you need drill-down, use logs or traces.
Async failures that never increment a counter are also common. Wrap the whole turn lifecycle, not just the happy-path API call. If a websocket disconnects midway through synthesis, count that as a failure in the metrics that matter.
Histogram boundaries should reflect the actual latency distribution you expect. If most synthesis takes 100–700 ms, buckets around that range are more useful than generic defaults.
Scrape intervals need to match the system behavior. For realtime agents, a 15–30 second scrape is usually fine for dashboards, but alerting on sharp spikes may need shorter windows or recording rules.
Separate infra from product signals. CPU, memory, and network stats are important, but they do not replace application-level metrics. A healthy pod can still be producing broken avatar sessions.
How Protoface fits into this workflow
When the voice agent also drives a realtime avatar, you want the avatar layer to be visible in the same operational picture as the agent itself. That is exactly where Protoface is useful: it gives you a synchronized talking face for a voice agent, and you can treat the avatar session as another observable part of the system rather than a separate black box.
In practice, that means you can instrument your ElevenLabs turn lifecycle, then correlate those metrics with avatar session behavior created through the Protoface REST API, Python SDK, or the LiveKit Agents plugin. If you are using the LiveKit integration, the plugin path is especially useful because it sits directly in the agent loop, which makes it a natural place to increment counters for turn start, synthesis completion, and session disconnect. If you want the implementation details, start with the docs and the quickstart repo for your agent stack: docs.protoface.com and the ElevenLabs agents quickstart.
Here is a small illustrative example of creating an avatar session from Python. The exact request fields depend on the API shape in the docs, so treat this as a pattern rather than a copy-paste endpoint spec.
The operational payoff is straightforward: once you can see session starts, failures, and latency around the voice agent and avatar together, you can distinguish “LLM is slow,” “TTS is slow,” and “video face is lagging” without guessing.
Conclusion
If you are exporting ElevenLabs metrics to Prometheus for a realtime avatar product, focus on the metrics that explain user-visible behavior: turn latency, synthesis errors, session churn, and avatar lag. Expose them from the agent process, scrape them with Prometheus, and build Grafana dashboards around percentiles and failure rates rather than averages.
From there, add alerts for the things that break conversations: rising P95 latency, elevated disconnects, and render lag that diverges from synthesis latency. If you are integrating a synced avatar layer, use the relevant Protoface surface for your stack and keep the metrics close to the agent lifecycle so you can correlate the two cleanly. The docs at docs.protoface.com and the quickstart repos are the fastest way to adapt this pattern to your own agent.