CloudWatch

Amazon CloudWatch holds the metrics and logs your AWS services emit. Investigations query it to see how a service behaved around the time of an incident — the error rate that climbed, the function that started timing out, the log line that appeared right after a deploy.

​

What we support

CloudWatch is one data source with two surfaces, and investigations query both:

• Metrics — CloudWatch Metric Math over AWS service metrics (EC2, RDS, Lambda, ELB, etc.) and any custom metrics your application publishes. Investigations graph a counter climbing, a latency percentile spiking, or a queue backing up across the incident window.
• Logs — CloudWatch Logs Insights (CWLI) over your AWS and application log groups. Investigations pull the actual log lines a service wrote, or aggregate them to count error patterns and break latency down by route.

​

Searching logs across services

A CWLI query runs against named log groups, and investigations can scan several at once — the Lambdas behind one service, or a service and its load balancer — in a single query, surfacing which group each line came from. That turns “where did this request fail” into one search across the path it took, rather than one query per service. CWLI also reads structure straight out of your logs. JSON log lines expose their top-level keys as queryable fields, and AWS-managed formats (Lambda runtime logs, CloudTrail, VPC Flow Logs) are parsed automatically, so investigations filter on a status code, request ID, or level without you indexing anything. For plain-text logs, fields are carved out by pattern at query time.

​

Metric namespaces and dimensions

CloudWatch metrics live under namespaces (AWS/Lambda, AWS/RDS, or a custom namespace like MyApp/Checkout), each with its own dimensions for grouping — by function, instance, database, and so on. Investigations prefer your custom namespaces first, since those encode what your team chose to measure, before falling back to the AWS-managed ones. Investigations learn this structure — your log groups and their field shapes, your populated namespaces, their metrics and dimensions, and which regions each appears in — automatically. How that works is covered in How telemetry works.

​

Connecting CloudWatch

CloudWatch is discovered when you connect a provider. There are two routes, and both give investigations the same access.

​

Via AWS

Connect AWS with an IAM role incident.io assumes, and CloudWatch is discovered automatically for the accounts and regions you enable. Investigations query it directly through the AWS APIs using those credentials — nothing CloudWatch-specific to configure.

​

Via Grafana

If your CloudWatch already sits behind Grafana, connect Grafana and CloudWatch is discovered as one of the data sources behind it, queried through Grafana’s own credentials. Either way, CloudWatch is disabled by default. Log queries can be broad, so you opt in deliberately — enable the CloudWatch data sources your team uses once they’re connected.

​

Best practice

• Enable only the accounts and regions your responders actually reach for during incidents. CloudWatch is region-scoped, so the same service can appear in several regions independently.
• Scope the credentials to read-only access. Investigations only ever read from CloudWatch, never change anything.
• If you reach CloudWatch through Grafana, connect the dashboards that query it. Investigations learn your real query patterns from them, which makes CloudWatch queries more accurate.

​

Related