Skip to content

AWS Updated 2026-07-04

EC2 instance status check failed (1/2 or 2/2): what each check means and how to recover

An EC2 status check failed alert means either AWS's hardware layer or your operating system is unhealthy. Here is what each check tests, how to tell which one failed, and the recovery path for each.

EC2 runs two independent health checks against every running instance, and “1/2 checks passed” tells you which side of the line the failure is on. The system status check tests the AWS layer — the physical host, its network, its power. The instance status check tests your layer — whether the operating system boots, responds on the network, and is not wedged in a kernel panic. The recovery differs completely: a system check failure is fixed by moving the instance to new hardware (stop/start, or automatic recovery), while an instance check failure means something inside your OS is broken and no amount of hardware migration will fix it.

What’s happening

Every minute, EC2 checks each instance from outside. The system status check verifies the underlying host: loss of network connectivity at the host level, loss of power, software or hardware problems on the physical server. You cannot fix these — only AWS can, and your lever is getting your instance onto a different host. The instance status check verifies the guest: it fails on a corrupted filesystem, an exhausted memory condition, a kernel panic, a mangled network configuration inside the OS, or a boot that never completed. Those are yours to fix.

There is a third, newer surface: attached EBS status checks, which report whether the volumes attached to the instance are reachable and completing I/O. A stuck EBS volume can make an instance look dead while both classic checks still tell the truth about where the fault sits.

The critical operational fact: a reboot keeps the instance on the same physical host, while a stop/start migrates it to a new one. That is why reboot fixes almost nothing when the system check fails, and why stop/start is the standard recovery. Note that stop/start changes a non-Elastic public IP and wipes instance store volumes — see instance store vs EBS before you pull that lever on an instance with local disks.

What to check first

  • Which check failed? EC2 > Instances > select instance > Status checks tab. System failure and instance failure lead to different runbooks — do not guess.
  • Is there an active AWS incident? Check https://health.aws.amazon.com/ and your Personal Health Dashboard. A host-level event sometimes comes with a scheduled retirement notice.
  • Is this one instance or several? Multiple instances failing in one AZ points at an AWS-side event; a single instance failing points at that instance.
  • Did anything change recently? A kernel update, a fstab edit, a memory-hungry deploy — instance check failures usually follow a change or a slow resource leak.
  • Do you have a recent snapshot or AMI? Know your fallback before you start recovery, not after.

How to verify

Pull the check status and its history:

aws ec2 describe-instance-status --instance-ids i-0123456789abcdef0 \
  --query 'InstanceStatuses[].[InstanceState.Name,SystemStatus.Status,InstanceStatus.Status]' \
  --output table

# When did it start failing?
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name StatusCheckFailed_System \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-07-03T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 300 --statistics Maximum

Swap StatusCheckFailed_System for StatusCheckFailed_Instance to see the other side. For an instance check failure, get eyes on the OS without SSH: EC2 > Instances > Actions > Monitor and troubleshoot > Get system log shows the boot output, and Get instance screenshot shows what a monitor would — a kernel panic, a filesystem check prompt, or a login screen (which would mean the OS is fine and only networking is broken). If the instance is Nitro-based, the EC2 serial console gives you an interactive session that does not depend on networking. The full troubleshooting matrix is in the EC2 docs at https://docs.aws.amazon.com/ec2/.

The runbook

  1. System status check failed: stop and start the instance. Not reboot — stop, wait for stopped, then start. The start lands on healthy hardware and the check clears in a couple of minutes. Before stopping: confirm no instance store volumes hold unreplicated data, and expect the public IP to change unless you use an Elastic IP.
  2. System check failed and you cannot take downtime decisions manually: rely on simplified automatic recovery or a recovery alarm. Most current instance types recover automatically on host failure; you can also create a CloudWatch alarm on StatusCheckFailed_System with the recover action, which migrates the instance while keeping instance ID, private IP, and Elastic IP. Recovery does not work on instances with instance store volumes.
  3. Instance status check failed: read the system log first. Kernel panic, fsck waiting for input, out-of-memory kills, or a bad /etc/fstab entry each show up plainly in the console output. Fix what the log names: reboot clears a wedged kernel or OOM condition temporarily; a bad fstab entry needs rescue-mode editing.
  4. Instance check failed and the OS will not boot: rescue via volume swap. Stop the instance, detach the root EBS volume, attach it to a healthy helper instance as a secondary volume, mount it, repair (fix fstab, remove the broken kernel from the boot config, run a filesystem check), unmount, reattach as the root device, start. The serial console can save you this entire dance on Nitro instances when the problem is a config file.
  5. Attached EBS check failed: treat it as a volume event, not an instance event. Check the volume’s status in EC2 > Volumes, and if I/O is disabled after a volume event, re-enable it after assessing consistency. Restoring from a snapshot is the honest fallback for a damaged volume.

When this is the wrong move

If the instance is part of an Auto Scaling group behind a load balancer, do not hand-nurse it — terminate it and let the ASG replace it. Manual recovery is for pets: databases, stateful singletons, anything not trivially rebuildable. Also, if status checks pass but the application is down, this runbook does not apply — the checks test host and OS health, not your application; that gap is what ELB health checks and a proper CloudWatch alarm baseline exist to cover.

Common mistakes

  • Rebooting repeatedly on a system check failure — reboot stays on the same broken host; stop/start is what moves you.
  • Stopping an instance with instance store data before copying it off, and learning the ephemeral lesson the hard way.
  • Waiting hours for AWS to fix a failed host under you when a stop/start would have recovered service in minutes.
  • Treating a passed 2/2 as proof the application works — the checks stop at the OS.

Prevention

  • Create CloudWatch alarms on both StatusCheckFailed_System (with the recover action where supported) and StatusCheckFailed_Instance so you hear about failures before users do.
  • Keep AMIs or tested snapshots of anything you would hate to rebuild — recovery decisions are calmer with a known-good fallback.
  • Run stateful workloads on EBS, and treat instance store as scratch space only.
  • Subscribe to Personal Health Dashboard notifications; scheduled host retirements give you a maintenance window instead of a 3 a.m. page.
  • Put anything replaceable in an Auto Scaling group so recovery is termination, not surgery.

Status check failures are one of the few AWS problems where the console literally tells you whose fault it is — read which check failed and the path is short. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.