AWS EC2 Health Check Fails – Fix It Fast

1. Memory Leak or Out of Memory (OOM)

This is the number one reason I see EC2 health checks fail. The instance just stops responding. It's still running in AWS, but you can't SSH in, and the status check shows 1/2 checks passed or instance reachability check failed. Most of the time, it's because an app ate all the RAM. I had a client last month whose WordPress site on a t2.micro started failing health checks every few hours. Turned out a plugin had a memory leak.

The fix: You can't SSH in, so you have to stop the instance from the AWS console. Go to EC2 > Instances, select the instance, click Instance state > Stop. Wait a few minutes, then start it again. That clears the memory. Once it's back up, SSH in and run free -m to check memory usage. Also look at dmesg | grep -i oom—that'll show you if the kernel killed a process due to OOM.

To prevent it, add swap space if your instance type allows it. Or upgrade to a bigger instance class. But really, the quick fix is stop/start. Don't just reboot—reboot doesn't clear memory on AWS in the same way. Stop/start actually moves the instance to a new host, which gives you a clean slate.

2. Disk Space Full

Second most common cause: the root volume fills up. When the disk is 100% full, the OS can't write logs, can't start services, and eventually stops responding to health checks. I've seen this on Jenkins build servers that don't clean up old logs. The EC2 instance passes status checks but fails system checks because the OS can't function.

The fix: Same as above—you'll probably need to stop and start the instance from the console to regain access. But if you still have SSH access (sometimes disk full doesn't kill SSH), log in and run df -h to see what's full. Then clear space: sudo journalctl --vacuum-size=200M (if using systemd), or delete old log files in /var/log/. I had a client last week whose /var/log/syslog was 12GB—one file. Big yikes.

To prevent it, set up log rotation with logrotate. AWS also lets you add EBS volumes and move logs there. Or set up CloudWatch Logs to stream logs and delete local copies. But if you're in a hurry, stop/start and delete logs is the fastest fix.

3. Kernel Panic or Hardware Issues

This one's rarer but happens. A kernel panic stops the OS dead. The EC2 status check will show instance reachability check failed and you won't get any response from SSH. Sometimes it's a bad EBS volume, sometimes it's a driver issue after an update. I had a client where a yum update on Amazon Linux 2 broke the kernel module for the NVMe driver.

The fix: First, try a stop/start from the console. If that doesn't work (the instance starts but fails again), you need to check the system log. In the EC2 console, select the instance, go to Actions > Monitor and troubleshoot > Get system log. Look for lines like Kernel panic - not syncing. If you see that, you'll need to recover by detaching the root volume, attaching it to a working instance, and chrooting in to fix it. That's an advanced move—if you're not comfortable, restore from a snapshot or launch a new instance.

For hardware issues (rare on AWS, but happens with older instance types), a stop and start usually moves you to different hardware and fixes it. If it doesn't, open a support ticket.

Quick-Reference Summary Table