Search Logs with CloudWatch Logs Insights

Start with time, log groups, and a limit

Choose the relevant log groups and a narrow absolute time range in the console before running queries. Logs Insights Query Language examples below can be pasted into the query editor and adapted to your actual messages.

fields @timestamp, @logStream, @message
| sort @timestamp desc
| limit 50

Search error and lock events

fields @timestamp, @message
| filter @message like /ERROR|FATAL|PANIC|deadlock|lock timeout/
| sort @timestamp desc
| limit 100

Match actual engine severity text and message format. Review context around each event; a generic word search alone can return unrelated lines.

Count event volume over time

filter @message like /ERROR|FATAL/
| stats count(*) as error_count by bin(5m)
| sort bin(5m) asc

Use a time bin that fits the symptom and chosen time range. A count spike helps locate when event volume changed but does not identify root cause.

Extract PostgreSQL statement durations

When PostgreSQL log messages include duration lines, a regular expression can extract the duration. The exact pattern depends on server version and log prefix, so inspect raw messages and adapt it.

fields @timestamp, @message
| filter @message like /duration:/
| parse @message /duration: (?<duration_ms>[0-9.]+) ms/
| filter duration_ms > 1000
| sort duration_ms desc
| limit 100

This works only for duration events that were actually logged and whose message matches the pattern. It finds completed statements; it does not reveal every active query. Search data can include SQL text and must be handled as sensitive.

Make query work repeatable

• Name and document saved queries with engine, log group, and expected format.
• Keep the time range narrow and limit output while exploring.
• Refine and test patterns against raw messages before drawing conclusions.
• Track scanned bytes, duration, and query purpose; avoid repeated broad scans.
• Export only approved, redacted evidence to an incident.