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 |
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.