How to Measure AI Voice Agent Latency in Amazon Connect, Turn by Turn

On a call, latency is not how long a request takes. It is the silence the caller hears between finishing a sentence and hearing the first word of the answer. People notice that gap quickly. Research on conversation across ten languages (Stivers and colleagues, 2009) found the typical gap between speakers is only around 200 milliseconds, so anything the caller perceives as a pause is long by human standards. You do not need to hit that number, since callers know they are talking to a system, but it explains why a two-second pause feels like something went wrong.

A single average hides most of the problem. A call can average 1.2 seconds per turn and still contain one eight-second silence that makes the caller hang up. That is why this guide is about a turn-by-turn view: one row per caller turn, with the delay split into the stages that cause it.

We checked the AWS documentation referred to below on 10 November 2026. Metric names and log fields change, so verify them against your own account before building dashboards. If you are still building the agent, start with How to Add an AI Voice Agent to Amazon Connect.

Each turn passes through the same stages. Knowing them lets you assign a number, and an owner, to each part of the pause.

One setting is a hidden floor under every turn. AWS documents default speech settings for the advanced speech model of a 0.7 end-of-turn confidence threshold and a 640 millisecond silence timeout, adjustable between 500 and 10,000 milliseconds. The silence timeout is time the system waits to be sure you have finished, so lowering it shortens every turn but raises the risk of cutting callers off. Measure before and after you change it.

Two notes from the documentation matter in practice. The Lex runtime latency metric is spelled RuntimeSucessfulRequestLatency, with that spelling, and AWS calls this out. And the Connect Bot Analytics page only shows conversations triggered from flows, not bots invoked directly through Lex APIs.

We did not find a single AWS metric that reports 'time from the caller stopping to the agent speaking' for an Amazon Connect call, and none that splits it into the stages above for agentic self-service. The pieces exist in different places, with different clocks. That is not a flaw in your setup. It simply means the turn-by-turn view is something you build, and the rest of this guide shows how.

If AWS has added such a metric since our check, use it, but still keep the per-stage numbers, because the stages are where you find the fix.

Conversation logs are configured per bot alias, and they only record conversations that happen after you enable them. You cannot reconstruct last week's calls later, so switch them on in the test environment and keep them on in production.

1. Open the bot alias you route calls to and enable text logs, which store transcripts and metadata in CloudWatch Logs.
2. Enable audio logs as well if you are allowed to store caller audio. They go to Amazon S3, and the log entry records the audio duration, how much of it was speech and how much was silence.
3. Encrypt both with a customer-managed KMS key.
4. Use Lex's option to obscure slot values so names, numbers and dates do not sit in plain text in the logs.
5. Set a retention period for the log group that matches your data policy.

Logs hold personal data. AWS notes that conversation logs cannot be used with bots subject to COPPA, and you should treat the rest as you would any call recording: restrict access, redact where you can, and delete on schedule. See Logging conversations with conversation logs.

Start with a dashboard of the aggregate metrics, because it tells you whether a problem is everywhere or only in some calls.

• Lex: RuntimeSucessfulRequestLatency at p50 and p95, RuntimeRequestCount, RuntimeThrottledEvents, RuntimeLambdaErrors and RuntimePollyErrors, split by InputMode so speech is separate from text.
• Bedrock: InvocationLatency and TimeToFirstToken at p50 and p95 for the model you use, plus OutputTokenCount and InvocationThrottles. Long answers take longer, so compare latency against output tokens, which AWS also documents a way to do.
• Lambda or your tool APIs: duration at p95 for each function the agent calls.
• Connect: average bot conversation time and turns, filtered by outcome, to see whether slow calls end badly.

For voice, TimeToFirstToken is usually more informative than InvocationLatency, because speech can start once the first words arrive. That only holds if your design streams the reply to the voice layer. Check how your own architecture uses the model before reading too much into either number.

The report is one row per caller turn. Take the Lex conversation log as the spine, because it gives each turn an ID and a timestamp, then attach the other timings to it by session and time.

A starting point in CloudWatch Logs Insights, against the Lex text log group for your alias, is a query that lists each turn in order with its audio and barge-in fields. Field names depend on how your log group is parsed, so treat this as a sketch to adapt.

fields @timestamp, sessionId, requestId, inputMode, inputTranscript,
       audioProperties.duration.total, audioProperties.duration.silence,
       bargeIn, responseReason, missedUtterance
| filter inputMode = "Speech"
| sort sessionId, @timestamp asc
| limit 500

The one number the logs do not hand you is the real gap the caller heard. The most reliable way to get it is from the call recording: find where the caller's speech ends and the agent's begins, either by listening on a test set or with a small script that detects speech boundaries in the two channels. If you control the application layer, you can also log your own timestamps at three points, when the transcript arrives, when the model starts to answer, and when audio is handed to the voice layer. Either route works. What matters is using one method consistently, so before and after numbers compare fairly.

• Report p50, p90 and p95, not the mean. The mean hides the pauses that make people hang up.
• Split by turn number. The first turn often carries extra work such as identity lookup or a greeting, and later turns can slow down as the conversation history grows.
• Split by whether a tool was called. Turns with tool calls will be slower, and that is the cost your tool design controls.
• Split by voice option and by channel. A mobile caller in a noisy place and a landline caller will not see the same numbers.
• Show the worst ten turns each week with their transcripts. Reading them tells you more than any chart.

A short weekly table is usually enough: turns measured, p50 and p95 gap overall, p95 per stage, share of turns with barge-in, and share of calls that ended with a transfer or a drop. Keep the same layout from week to week so the trend is obvious.

Here is a layout for one call, with invented numbers to show the shape. The point is the pattern a report makes visible, not the values.

Read it the way you would at review. The model is steady at about half a second, so it is not the problem. Turns 3 and 4 are slow, and the tool time explains most of the gap. The barge-in on turn 4 suggests the caller started talking because the wait felt too long. The fix is in the booking lookup, not the model or the voice. Without a per-turn view, the call would simply have averaged to about two seconds and nobody would know why it felt slow.

Add one more column once you have it: the transcript confidence. A turn that is slow and also low confidence often means the system waited for the caller to repeat themselves, which is a recognition problem wearing a latency costume.

Once the metrics exist, put alarms on the ones that change first. CloudWatch alarms can watch the Lex and Bedrock metrics directly.

Choose thresholds from your own week-one baseline, not from a number in a blog post. An alarm that fires all day gets muted, and then it protects nobody. Start loose, tighten as you learn what normal looks like, and send alerts to the person who can actually change the tool or the prompt.

Change one thing at a time and re-run the same call set. If you change the model and the prompt together you will not know which one moved the number.

We do not quote a universal target, because the right gap depends on the task and the caller. A simple intake call tolerates a little more than a quick yes or no. What we do recommend is deciding your own thresholds from listening. Record a test set of realistic calls, play them to people who were not involved in the build, and ask at which point a pause feels wrong. Use that to set a p95 target, then track against it.

1. Write a script of 15 to 20 caller turns that includes names, numbers, a correction and one question that needs a lookup.
2. Call from a mobile phone, at least twice at different times of day, and once from a noisy place.
3. Run the script a few dozen times so p95 means something. A handful of calls cannot show a tail.
4. Keep the script, the voice, the model and the prompt fixed while you change only the setting under test.
5. Record every call, and keep the logs, so you can go back to a bad turn.

For the architecture choices that move these numbers, see our architecture and build guide, the voice options guide, and Amazon Lex vs AI Agent in Amazon Connect. To have latency measured and tuned on your own call flow, see our AI voice agent development service.

• Conversation logs are on for the live alias, with a customer-managed key, slot obscuring and a retention period.
• A dashboard shows Lex, Bedrock and tool latency at p50 and p95, with speech separated from text.
• You know your silence timeout and end-of-turn settings, and have tested one change in each direction.
• Every tool has a time budget, and the slowest one has been reviewed for caching or an asynchronous path.
• The prompt tells the model to keep spoken answers short.
• You have a recorded test set and a baseline p95 gap from it.
• Alarms exist for throttling and for p95 drift, and someone owns them.
• A failed or slow tool leads to a spoken holding message or a transfer to a person, never to silence.

If you can tick every line before launch, the first week of real calls will teach you something. If you cannot, the first week will teach you only that callers hang up.