EC2 Status Checks Failed (1/2 or 2/3): The Real Fix
When EC2 shows "Instance status check failed" or "1/2 checks passed," here is the counterintuitive rule that solves most of them: don't reboot — Stop the instance, then Start it again. They sound identical. They are not. A reboot restarts your operating system on the same physical host — if that host's hardware is the problem, you restart straight back into it. Stop/Start releases the machine and brings it back up on different hardware. When the failed check is on AWS's side, reboot is a lullaby and Stop/Start is the cure.
Ethan learned the difference the annoying way — three reboots in a row on a dead-to-the-world instance, each one a little ritual of hope, before discovering the two buttons weren't synonyms. Nothing in the console explains this; the design gives you both buttons side by side and lets you assume. So this post is the explanation the console owes you: what each check actually watches, which fix belongs to which failure, and the one warning to read before you press Stop.
The EC2 status checks, decoded: System, Instance, and Attached EBS
Every running instance is probed about once a minute, free, and the results live on the Status checks tab. Depending on when your account and region got the update, the console shows two checks ("2/2 checks passed") or three ("3/3"):
| Check | What it watches | Whose problem it is |
|---|---|---|
| System status check | The physical host: its power, its network, its hardware | AWS's side |
| Instance status check (reachability) | Your OS: did it boot, is its networking sane, is it responding | Your side |
| Attached EBS status check (newer consoles) | Whether your EBS volumes are reachable and completing I/O | The storage layer |
That single table is the whole diagnosis: read which check failed before touching anything, because the two failures have opposite fixes.
System status check failed: AWS's hardware, your Stop/Start
A failed system check means the host machine under your instance is unwell — hardware fault, power event, or the host's network dropped. You cannot repair AWS's server, and you don't have to. You just have to leave it:
Instance state → Stop. Wait for Stopped (not Stopping). Then Instance state → Start. Your instance comes back on a healthy host, your EBS volumes follow it automatically, and in most cases both checks go green within a couple of minutes.
The warning that belongs right next to that button: Stop/Start changes your public IPv4 address unless you use an Elastic IP. If anything points at the old address — a DNS record, a teammate's script, your own SSH shortcut — update it, or you will graduate directly into the errors covered in our EC2 connection timed out / refused guide. (Also: instance-store volumes, rare for beginners, are erased by a Stop — EBS-backed instances, the default, are safe.)
Set it and forget it: CloudWatch has a purpose-built alarm action called Recover for exactly this failure — it watches StatusCheckFailed_System and performs the migration for you, automatically, while you sleep. Creating it takes two minutes on the instance's Monitoring tab and turns this entire section into something that happens without you.
Instance status check failed: your OS, and the system log tells you why
A failed instance (reachability) check means AWS's hardware is fine but your operating system isn't answering — it failed to boot, wedged itself, or broke its own networking. Reboot is a legitimate first move here (unlike above), but if it doesn't stick, stop guessing and read the evidence: Actions → Monitor and troubleshoot → Get system log. That is your machine's boot console, readable from outside, and it usually names the killer:
Out of memory — the classic on t2/t3.micro machines with 1 GB of RAM: the log shows Out of memory: Killed process.... Something on the box (often a runaway app or an ambitious database) ate the gigabyte. Fix: a bigger instance type, or add swap, or stop running MySQL and three Node apps on a micro.
Kernel panic / failed boot after an update — the log stops at Kernel panic or grub errors, typically right after a kernel upgrade. Fix for the brave: stop the instance, detach the root EBS volume, attach it to a healthy helper instance, repair (roll back the kernel or fix /etc/fstab), reattach, start. Fix for the pragmatic: restore the volume from a snapshot — which is the argument for having snapshots.
Broken fstab or network config — the log shows a mount failing or cloud-init erroring. Same rescue-volume dance as above; the log line tells you which file to fix.
Attached EBS check failed: the storage layer is the patient
On consoles showing three checks, a failed Attached EBS check means a volume is impaired — I/O not completing. Check the volume's own status in the EC2 → Volumes view. The usual paths: if the volume shows impaired, a Stop/Start often re-establishes it on healthy storage infrastructure; if it stays sick, restore the latest snapshot to a new volume and swap it in. If you have no snapshot, this is the day that changes your snapshot policy.
The rescue-volume operation, step by step — for when the OS will not boot
The kernel-panic and broken-fstab fixes above both end in the same operation, so here it is once, properly. You are going to perform surgery on the sick machine's disk from a healthy machine's bedside:
1. Stop the sick instance (note its root volume — usually /dev/xvda — on the Storage tab). 2. In EC2 → Volumes, detach that root volume. 3. Attach it to a healthy instance in the same Availability Zone as a secondary disk (it will arrive as something like /dev/sdf). 4. On the healthy machine: sudo mkdir /rescue && sudo mount /dev/xvdf1 /rescue — your sick machine's entire file system is now a folder you can edit. 5. Make the repair: roll back the kernel entry in grub, comment out the bad line in /rescue/etc/fstab, undo whatever last night's change was. 6. Unmount, detach, and re-attach to the original instance with the exact original device name (/dev/xvda — this detail is the whole operation; the wrong name and it will not boot). 7. Start the instance and watch the check go green.
Twenty minutes, no data loss, and the first time you do it you stop fearing instance checks forever. If even reading this list felt like too much at 1 a.m. — that is the honest argument for snapshots, where the fix is "restore and go back to bed."
Checking status from the CLI — one command, no console
When the console is slow or you are scripting, the same truth is one command away:
aws ec2 describe-instance-status --instance-id i-0abc123 --include-all-instances
The output carries two blocks — SystemStatus and InstanceStatus — each with ok, impaired, or initializing. The --include-all-instances flag matters: without it, stopped instances are silently omitted and your script concludes everything is fine. (The flag name is the documentation's quiet admission that the default behavior surprises people.)
The CloudWatch metrics behind the checks — StatusCheckFailed and friends
Every check publishes a free CloudWatch metric at one-minute resolution: StatusCheckFailed_System, StatusCheckFailed_Instance, StatusCheckFailed_AttachedEBS, and the combined StatusCheckFailed — each simply 0 (passing) or 1 (failing). This is what turns a health probe into automation: the Recover alarm from earlier watches the System metric; a plain alarm on the Instance metric can page you or trigger a reboot action; and on the Monitoring tab the graph of these metrics is a timeline of every wobble your instance ever had — worth a glance before you blame last night's deploy for a problem that started last Tuesday.
CPU credits — when every check passes and the instance still crawls
One neighboring trap belongs here because it wears the same symptoms. Burstable instances (t2, t3, t4g — including the free-tier machines) earn CPU credits while idle and spend them under load. Run out, and the instance is throttled to a fraction of a CPU: SSH takes thirty seconds, pages time out, everything feels broken — and both status checks pass, because the machine is technically healthy, just rationed. The tell: the CPUCreditBalance metric at zero. The fixes: let it rest, enable Unlimited mode (small surcharge), or admit the workload outgrew a burstable class. If your checks are green and users are screaming, look here first.
Preventing the next one — the four-line resilience checklist
One: the CloudWatch Recover alarm on every instance you care about (two minutes, covered above). Two: automatic EBS snapshots on a schedule — Amazon Data Lifecycle Manager does daily snapshots with retention for free; the rescue-volume section above becomes optional reading once these exist. Three: an Elastic IP on anything other machines point at, so the Stop/Start cure never breaks your address. Four: before any kernel or fstab change, take a snapshot first — the sixty-second habit that converts every catastrophe in this post into an inconvenience.
"0/2 checks passed" right after launch — the one that isn't a failure
A brand-new instance shows Initializing — and sometimes briefly 0/2 — for the first few minutes while checks warm up. This is the non-error that sends new users hunting for problems that don't exist. Give a fresh launch five minutes before you diagnose anything. (Windows instances in particular boot slower than the checks are patient.)
The decision table — pin this
| What you see | What it means | What actually fixes it |
|---|---|---|
| System check failed | AWS host is sick | Stop → Start (not reboot); or CloudWatch Recover alarm |
| Instance check failed | Your OS is sick | Reboot once → then Get system log → OOM/kernel/fstab fix |
| Attached EBS check failed | A volume is impaired | Volume status → Stop/Start → snapshot-restore if persistent |
| Both/all failed | Usually the host | Treat as System: Stop → Start |
| 0/2 just after launch | Checks still initializing | Five minutes of patience |
| Checks pass, SSH still fails | Not a health issue at all | Security groups & keys — see the connection errors guide |
Update, October 2026: automatic recovery, the EC2 Serial Console and scheduled events
Readers fixing failed status checks often ask how to stop being woken at night by them. Three EC2 features turn many of these incidents into non-events, and one gives you a way into instances that will not boot or accept SSH.
Let EC2 recover system check failures by itself
For a system status check failure, which points at AWS hardware, the fix described above is a Stop and Start so the instance moves to healthy hardware. EC2 can do this for you. Supported current-generation instance types have simplified automatic recovery turned on by default, which moves the instance to new hardware when AWS detects an underlying hardware problem, keeping its instance ID, private IP addresses and attached EBS volumes. You can check or change the behavior in the instance's settings under Change auto-recovery behavior. For more control, a CloudWatch alarm on StatusCheckFailed_System with the Recover this instance action does the same on demand, and can notify you through SNS at the same time.
Recovery only helps system check failures. Instance status check failures come from your operating system, so recovery or a reboot alarm action only helps if a restart actually clears the problem; the root cause in the system log still needs fixing.
The EC2 Serial Console: get in when SSH will not
When an instance fails its instance check because of a broken network configuration, a bad fstab entry or a kernel that drops into emergency mode, SSH and Session Manager are unreachable. The EC2 Serial Console connects to the instance's serial port directly, like plugging a keyboard into a physical server, on Nitro-based instance types. Enable serial console access for the account in the EC2 console settings, make sure the operating system has a user with a password for console login, and connect from the instance's Connect menu. It often replaces the rescue-volume procedure above for configuration mistakes, since you can fix the file and reboot in place.
Watch for scheduled events
AWS schedules maintenance events, such as instance retirement when hardware is degrading, and lists them under Scheduled events in the EC2 console and in AWS Health. An instance scheduled for retirement will eventually fail its system check if you do nothing. Stop and start it at a convenient time before the deadline to move it yourself. Subscribing to AWS Health notifications through EventBridge turns these into alerts instead of surprises.
Design so one failed instance does not matter
The longer-term answer for production is to run instances in an Auto Scaling group behind a load balancer, with health checks that replace unhealthy instances automatically, across more than one Availability Zone. Then a failed status check costs a replacement instance, not an outage, and your AWS bill grows only by the minutes of overlap.
More questions readers asked in October 2026
Does EC2 automatically recover from system status check failures?
On supported instance types, simplified automatic recovery is on by default. A CloudWatch alarm with the recover action gives more control.
How do I access an EC2 instance that fails its instance status check?
Use the EC2 Serial Console on Nitro instances, after enabling it for the account and setting an OS password, or use the rescue-volume method.
What is an instance retirement event?
AWS scheduling an instance's move off degrading hardware. Stop and start it before the deadline to avoid an unplanned failure.
Update added October 3, 2026. The original guide above is unchanged.
Questions People Actually Ask
What is the difference between reboot and stop/start on EC2?
Reboot restarts the OS on the same physical host. Stop/Start releases the hardware and brings the instance up on a different host — which is why it fixes system status check failures that reboot cannot touch. Stop/Start changes the public IPv4 unless you use an Elastic IP.
Does a failed status check cost me money?
The checks themselves are free and run every minute. A failed instance still bills while running; a stopped instance bills only for its EBS storage.
Can AWS fix a system status check failure automatically?
Yes — create a CloudWatch alarm on StatusCheckFailed_System with the Recover action. AWS then migrates the instance to healthy hardware automatically, keeping its instance ID, private IP, and Elastic IP.
Why does my instance show 1/2 checks passed?
One of the two probes is failing — open the Status checks tab to see which. System check failing means AWS-side hardware (fix: Stop/Start); instance check failing means your OS is not responding (fix: reboot once, then read the system log for out-of-memory or boot errors).
Will Stop/Start delete my data?
Not on EBS-backed instances (the default) — volumes persist and reattach. Only instance-store volumes, uncommon for beginners, lose data on Stop.