The AWS Alarm Just Fired. Now What?

An alarm just fired, or a search brought you here mid-incident. You don't need a deep dive right now — you need to know what this specific signal means and the first thing to check. Six of the most common CloudWatch signals that show up during an active AWS incident, each with the fast version and a link to the full guide if you need it after the fire is out.

• RDS CPU at 100%
• ECS task OOM-killed (exit code 137)
• EC2 StatusCheckFailed
• ALB UnHealthyHostCount above zero
• ALB RejectedConnectionCount above zero
• EC2 EBSIOBalance% near zero

RDS CPU at 100%

Sustained CPUUtilization at or near 100% on an RDS instance is almost always a query problem before it's a sizing problem — a missing index, a runaway query, or a sudden spike in connections doing full table scans. Before touching the instance class, open Performance Insights (or the RDS console's Monitoring tab) and check Top SQL / DB load by wait event for the current window. A single expensive query is the most common cause, and it's fixable without a resize or any downtime.

ECS task OOM-killed (exit code 137)

A stopped ECS task with exit code 137 means the container exceeded its memory limit and the kernel's OOM killer terminated it — a hard ceiling, not a slow leak you can wait out. Run `aws ecs describe-tasks` on the stopped task and check `stoppedReason` for "OutOfMemory": if it's a single task, look at what changed in the last deploy; if it's happening across the whole service, the task definition's memory limit is undersized for the workload.

EC2 StatusCheckFailed

StatusCheckFailed means either the instance itself (StatusCheckFailed_Instance) or the underlying host (StatusCheckFailed_System) is failing AWS's own health check — this is infrastructure-level, not an application error. Check which of the two sub-metrics actually fired: an instance-level failure is often fixed with a reboot, but a system-level failure means the physical host has a problem, and a stop/start (which moves the instance to new hardware) usually resolves it faster than waiting on AWS to fix the host.

ALB UnHealthyHostCount above zero

This means the load balancer's own health checks are already failing against one or more targets in the target group — traffic is being routed away from them, and if every target is unhealthy, requests start failing outright. Check the target group's health status in the console for the specific failure reason (timeout, non-2xx response, or connection refused) — that reason usually tells you immediately whether it's an app crash, a slow response, or a security-group misconfiguration.

ALB RejectedConnectionCount above zero

Unlike UnHealthyHostCount, this isn't about your targets at all — it means the load balancer itself refused a connection because it had already hit its own maximum capacity. AWS only reports this metric when it's nonzero, so any data point means real connections were dropped before ever reaching a target. Check whether this lines up with a sudden traffic spike outrunning the ALB's auto-scaling — if so, it's a load-balancer capacity problem, and your target-side health metrics can look completely normal at the same time.

EC2 EBSIOBalance% near zero

EBSIOBalance% is an instance-level metric — it tracks how much I/O burst credit the EC2 instance itself has left, separate from any BurstBalance on the attached EBS volumes. When it drops to 0%, the instance gets hard-capped to its baseline EBS IOPS rate and disk-bound operations queue up, even if the volume's own BurstBalance looks completely healthy. Check EBSIOBalance% (instance-level) separately from the volume's BurstBalance (volume-level) — if only the instance metric is depleted, the fix is a larger instance size, not a bigger or faster volume.

None of these fit? Check what's actually being monitored

These six cover a large share of what shows up mid-incident, but they're not exhaustive, and a signal you can't identify at all is its own kind of gap. A free Nuberio Audit scans your CloudWatch setup read-only and flags missing or misconfigured alarms across RDS, ECS, EC2, and ALB in under five minutes — worth running once the current fire is out, so the next one pages someone instead of getting found by accident.