Skip to content
Amazon Connect · Flow & Lambda logs

Amazon Connect CloudWatch Log Analyzer

Analyze contact flow, Lambda and Lex logs: draw each contact's path, find failing blocks, slow Lambdas and bot no-matches, with ready-made Logs Insights queries.

Last updated

Client-side only No data sent READY
CloudWatch Diagnostics
Amazon Connect CloudWatch Log Analyzer: flows, Lambda & Lex

Drop any Amazon Connect CloudWatch log — Contact Flow, Lambda, instance logs — and get instant structured analysis with error detection, Contact ID tracking, and smart remediation hints.

Multi-format: CloudWatch Insights JSON, text, Lambda, Contact Flow Error intelligence with remediation tips per pattern Contact Flow block-level execution timeline Lambda cold start, duration & memory analysis Log volume timeline + severity distribution chart Filter by level, stream, ContactId, or regex
// LOG SUMMARY
Log Input

Drop CloudWatch log file here

.log .txt .json .gz — any CloudWatch export format, parsed in your browser

or paste log text
Samples:
ms
Overview
Log volume over time
Severity distribution
Top Errors & Patterns
Anomaly Flags
Execution Timeline
Unique Contact IDs
Invocation Details
RequestIdDurationBilledMemory UsedMemory SizeInitStatusTime
Timestamp Level Stream / Source Message
—

Amazon Connect CloudWatch Log Analysis Guide

Amazon Connect writes detailed operational logs to Amazon CloudWatch Logs across multiple log groups. These include Contact Flow execution logs (every block execution, transfer, and error), Lambda function invocation logs, instance-level audit logs, and real-time metrics. Analyzing these logs is essential for troubleshooting call flow issues, diagnosing Lambda failures, auditing agent actions, and optimizing your contact center performance.

Where are Amazon Connect CloudWatch log groups located?
Connect logs appear in: /aws/connect/INSTANCE-ID (Contact Flow execution logs, one stream per ContactId), /aws/lambda/FUNCTION-NAME (Lambda function logs invoked from flows), /aws/connect/instance/INSTANCE-ID/contact-flow (flow-level logs), and custom log groups configured in your flows. Enable Contact Flow logs in the Amazon Connect console under Flows → Log group settings.
How do I enable Contact Flow logging in Amazon Connect?
Go to Amazon Connect console → Data Storage → Contact Trace Records → Enable Contact Flow logs. Alternatively, add a Set logging behavior block at the start of each contact flow with Enable Logging set to Yes. Logs appear in CloudWatch under /aws/connect/{instance-id} within seconds. Each contact creates a separate log stream named by ContactId.
What does a Contact Flow log entry look like?
A typical entry: {"ContactId":"abc-123","Identifier":"uuid","ContactFlowName":"Main Flow","ContactFlowModuleType":"PlayPrompt","Timestamp":"2024-01-15T10:32:01Z","Results":"Success"}. Error entries include an Error field describing what failed — e.g., Lambda timeout, invalid attribute reference, or missing queue. The ContactFlowModuleType tells you exactly which block type executed.
How do I diagnose Lambda timeouts in Amazon Connect flows?
Look for REPORT lines in Lambda logs with Duration close to the configured timeout (default 3s for Connect-invoked Lambdas, max 8s). Check for "Task timed out" in the error message. Common causes: slow DynamoDB queries, external API calls without timeout handling, VPC cold starts adding 500ms-2s latency. Increase Lambda timeout in Connect to max 8s and add circuit-breaker patterns in your Lambda code.
What is a cold start in AWS Lambda and how does it affect Connect?
A cold start occurs when Lambda must initialize a new execution environment — loading your code, runtime, and initializing the execution context. This adds 100ms–2s+ latency (more for Java/C#, less for Python/Node.js). In Connect flows, Lambda cold starts cause longer IVR response times. Mitigate with: Provisioned Concurrency, keeping functions warm with EventBridge scheduled pings, or using Lambda SnapStart (Java).
How do I use CloudWatch Logs Insights to analyze Connect logs?
Use queries like: fields @timestamp, ContactId, ContactFlowModuleType, Error | filter Error != "" | sort @timestamp desc | limit 50 to find all flow errors. For Lambda: fields @timestamp, @requestId, @duration, @billedDuration | filter @type="REPORT" | sort @duration desc to find slowest invocations. Export results as JSON and paste them directly into this tool for structured analysis.
How do I find a contact's path in Amazon Connect flow logs?
Contact flow logs record one line per block, each with the ContactId, block type, parameters and result. Paste or drop the logs here and open Contact paths: every contact is listed with its flows, duration, last block and issues, and clicking one draws its path block by block, with error branches, slow Lambda calls and loops highlighted. In CloudWatch itself, run the single-contact Logs Insights query below.
Why is my Amazon Connect Lambda timing out?
A Lambda function invoked synchronously from a flow must return within 8 seconds, or the block takes its error branch with 'The Lambda function invocation timed out'. Common causes are cold starts, slow downstream APIs, creating SDK clients on every call and functions with too little memory (which also limits CPU). The Lambda tab shows p50, p95 and p99 durations, calls near the limit, cold starts, throttles and peak memory.
How do I measure Lex no-match and fallback rates in Amazon Connect?
Each Lex or Get customer input block logs its result, such as the matched intent, FallbackIntent, NoMatchingCondition or Timeout. The Flow checks and Bots & AI tabs count results per block and per intent, show the failure rate, and list low-confidence matches so you know which utterances to add.
What does QueueAtCapacity mean in Amazon Connect logs?
It means a Transfer to queue block could not place the contact because the queue had reached its maximum number of contacts. The contact follows the At capacity branch. Raise the queue limit, add an overflow route or callback on that branch, and check your instance quotas.
Can I analyze a CloudWatch Logs Insights export here?
Yes. Export the results from the Logs Insights console as CSV or JSON, or download log events as .gz, and drop the file here. Everything is processed in your browser; nothing is uploaded.

CloudWatch Logs Insights queries for Amazon Connect

Copy these into CloudWatch Logs Insights to pull exactly what this analyzer reads. Paste or export the results back here for the full analysis.

Errors by flow and block

Run on your instance's flow log group (/aws/connect/<instance-alias>).

fields @timestamp, ContactFlowName, ContactFlowModuleType, Results
| filter ispresent(Error) or Results like /(?i)error|timed out|throttled|not found|capacity/
| stats count(*) as errors by ContactFlowName, ContactFlowModuleType, Results
| sort errors desc
| limit 50

One contact's journey

Replace the contact ID; paste the result back into this tool to see the path diagram.

fields @timestamp, ContactFlowName, ContactFlowModuleType, Identifier, Results, ExternalResults, Parameters.FunctionArn
| filter ContactId = "00000000-0000-0000-0000-000000000000"
| sort @timestamp asc

Lex and input failure rate per block

No-match, timeout and fallback counts for every input or Lex block.

filter ContactFlowModuleType in ["GetUserInput", "GetParticipantInput", "ConnectParticipantWithLexBot"]
| fields strcontains(Results, "NoMatch") + strcontains(Results, "Fallback") + strcontains(Results, "Timeout") as failed
| stats count(*) as runs, sum(failed) as failures by ContactFlowName, Identifier
| sort failures desc

Queue at capacity and transfer failures

Transfers that did not succeed, by flow and result.

filter ContactFlowModuleType like /Transfer/ and Results not like /(?i)success/
| stats count(*) as failures by ContactFlowName, Results
| sort failures desc

Lambda latency percentiles

Run on the Lambda function's log group (/aws/lambda/<function>).

filter @type = "REPORT"
| stats count(*) as invocations, avg(@duration) as avg_ms, pct(@duration, 95) as p95_ms,
        pct(@duration, 99) as p99_ms, max(@maxMemoryUsed / 1000 / 1000) as peak_mem_mb
  by bin(1h)

Lambda calls near the 8-second limit

Invocations that used more than 6 seconds — the ones about to time out in a flow.

filter @type = "REPORT" and @duration > 6000
| fields @timestamp, @requestId, @duration, @maxMemoryUsed / 1000 / 1000 as mem_mb
| sort @duration desc
| limit 50

Lambda cold starts

How often and how slow cold starts are, per hour.

filter @type = "REPORT" and ispresent(@initDuration)
| stats count(*) as cold_starts, avg(@initDuration) as avg_init_ms by bin(1h)

Amazon Connect flow log error reference

Common Results and error values in contact flow logs, what they mean and how to fix them. The analyzer flags all of these automatically.

Result or errorWhat it meansFix
The Lambda function invocation timed outThe function did not return within the Connect limit (8 s synchronous).Speed up the function, reduce cold starts, or use asynchronous invocation with a Wait block.
The Lambda function returned an errorThe function threw an error or returned an invalid response (for example not a flat key/value map).Check the function's own logs for the stack trace; return only string, number or boolean values at the top level.
The Lambda function was throttledLambda concurrency was exhausted.Raise reserved or account concurrency; check for runaway retries.
The Lambda function was not foundThe ARN in the block points to a function that does not exist or is not added to the instance.Add the function to the Amazon Connect instance and re-select it in the block.
Lambda invocation request too largeThe payload sent to Lambda exceeded the size limit.Send fewer or smaller contact attributes to the function.
NoMatchingConditionThe input did not match any branch or Lex intent.Add the missing options or utterances; give a clear retry prompt.
Timeout (input)The caller did not enter or say anything before the timeout.Lengthen the timeout slightly, repeat the question, and cap retries at 2–3.
FallbackIntentLex could not classify the caller's words.Add sample utterances from real calls; review overlapping intents.
QueueAtCapacityThe queue reached its maximum contacts.Raise the queue limit or route the At capacity branch to overflow or callback.
Error on CheckHoursOfOperationThe hours or queue the block uses could not be resolved.Re-select the hours resource; make sure it still exists.
Error on PlayPromptThe prompt, audio file or SSML could not be played.Check the prompt exists and the SSML is valid.
Practical guide

Tracing a failed contact through flow logs: a worked example

A customer says they were sent to the wrong queue after entering their account number. The CTR tells you where the contact ended up. The flow logs tell you why, because they record every block that ran, the parameters it used and the result it returned.

Step 1: Get the logs for one contact

Flow logs are written to the log group /aws/connect/<instance-alias>, but only for flows that ran a Set logging behavior block with logging enabled. In CloudWatch Logs Insights, select that log group and run:

fields @timestamp, ContactFlowName, ContactFlowModuleType, Results, Parameters
| filter ContactId = "your-contact-id"
| sort @timestamp asc
| limit 200

Export the results as JSON (or copy the raw events) and paste them here. The analyzer rebuilds the path block by block.

Step 2: Find where the path went wrong

Read the blocks in order. In this example the sequence is: GetUserInput (the customer typed the account number), then InvokeExternalResource (Lambda customer lookup), then CheckAttribute (tier = gold?), then SetQueue. The Lambda block's Results shows an error and the flow took the Error branch, which defaults to the general queue. So the routing is fine. The lookup failed.

Step 3: Follow it into the Lambda logs

Open the function's log group (/aws/lambda/<function-name>) at the same timestamp. Put the Connect ContactId in your function's logs, for example by logging event.Details.ContactData.ContactId on every invocation, so you can match the two log streams instantly. Paste the Lambda logs here too: the analyzer flags timeouts, cold starts and unhandled errors.

Common causes behind flow errors

  • Lambda timeouts. The Invoke AWS Lambda function block waits at most 8 seconds. A slow downstream API, a cold start in a VPC, or retries inside the function can exceed that even when the function eventually succeeds. Keep functions fast, set a client timeout well under 8 seconds, and consider provisioned concurrency for critical lookups.
  • Invalid response shape. For synchronous invocations Connect expects a flat set of key-value pairs. Nested objects or arrays are not accepted in the default response mode, and the block fails. Use the JSON response validation option if you need nested data.
  • Response too large. Keep Lambda responses small. Return only the attributes the flow needs.
  • Attribute name mismatches. $.External.Tier versus $.External.tier: attribute keys are case-sensitive, so a check silently fails to match and takes the default branch.
  • Logging switched off part-way. If a transferred-to flow or module doesn't enable logging, the trace just stops. Enable logging at the start of every flow you need to troubleshoot.

Useful Logs Insights queries

# Error branches taken in the last 24 h, by flow
fields ContactFlowName, ContactFlowModuleType, Results
| filter Results like /Error|Failed/
| stats count(*) as errors by ContactFlowName, ContactFlowModuleType
| sort errors desc

# Slowest Lambda invocations (Lambda log group)
filter @type = "REPORT"
| stats max(@duration) as maxMs, avg(@duration) as avgMs by bin(1h)

Remember that flow logging adds to CloudWatch Logs cost. Set a retention period on the log group, for example 30 to 90 days, rather than keeping logs forever.

Official references

Connect CCP Log Parser Connect CTR Parser Connect Agent Workstation Validator AWS CloudTrail Log Analyzer AWS Unix Timestamp Converter AWS JSON Formatter

Related guides on the Kloudmint blog

Guide Amazon Connect Lambda Timeout Errors: How to Fix Guide Amazon Q in Connect Agent Assist: Step-by-Step Setup Guide Stop the Amazon Connect AI Agent Infinite Reasoning Loop
Runs 100% in your browser. Your files and data never leave your machine. Nothing is uploaded or stored.

Stuck on an Amazon Connect problem?

Get help from an architect with 8+ years in contact centres and 4+ years on Amazon Connect: flows, CCP and CRM integrations, Lex and Q in Connect, migrations and go-lives.

Talk to an architect