Aws Cloudwatch Investigation

Think of this as the playbook you'd otherwise rebuild from memory at 2 a.m. It packages four investigation patterns for CloudWatch: Logs Insights query templates for error spikes, OOM kills, cold starts, and timeouts; a method for matching alarm transitions to CloudTrail deploy events within a 30-minute window; a top-down decision tree that narrows scope from account to region to service to resource; and metric math expressions for error rate, latency-versus-baseline, and a throttling pressure score. The triage order is the most useful part, since it stops you from chasing a single Lambda when the real culprit is a shared NAT gateway or an IAM throttle. The queries are untested against your log schema, so expect to adjust field names like `operation` and `@duration` for custom logging, and the CloudTrail Lake query needs your own event data store ID.

GitHub stars: 37.4K
last updated: Aug 1, 2026

View on GitHub

Install

$ npx -y skills add github/awesome-copilot --skill aws-cloudwatch-investigation --agent claude-code

Installs into .claude/skills of the current project.

Files

AWS CloudWatch Investigation Skill

Reusable patterns for investigating production incidents using CloudWatch Logs, Metrics, and Alarms. These patterns are designed to be composed together during incident triage.

Pattern 1: Logs Insights Query Templates

Error Spike Detection

Find the top errors in a time window, grouped by error type:

fields @timestamp, @message, @logStream
| filter @message like /(?i)(error|exception|fatal|critical)/
| stats count(*) as errorCount by bin(5m), @logStream
| sort errorCount desc
| limit 20

P99 Latency Breakdown by Operation

Identify which operations are driving latency spikes:

fields @timestamp, @duration, operation
| filter ispresent(@duration)
| stats avg(@duration) as avgMs,
        pct(@duration, 50) as p50Ms,
        pct(@duration, 95) as p95Ms,
        pct(@duration, 99) as p99Ms,
        count(*) as invocations
  by operation
| sort p99Ms desc
| limit 15