Introduction

When an EC2 instance shows 1/2 checks passed, AWS is telling you that one of its two health domains is failing. That means the instance should be treated as degraded even if it is still partially reachable. Good recovery depends on knowing whether the failing check is on the AWS host side or inside the guest operating system.

Understand the Two EC2 Status Checks

EC2 reports two main status checks:

• System status check: health of the underlying AWS infrastructure.
• Instance status check: health of the operating system running inside your VM.

If the system check fails, the problem is usually outside the guest and may involve the physical host or network substrate. If the instance check fails, the issue is more likely inside the VM, such as a failed boot process, broken networking, or a full root filesystem.

The fastest way to confirm the failure type is with the AWS CLI:

aws ec2 describe-instance-status \
  --instance-ids i-1234567890abcdef0 \
  --include-all-instances

That response tells you which branch of your incident runbook to follow.

Collect Evidence Before Taking Disruptive Actions

People often reboot immediately, but it is better to collect a small amount of evidence first. Console output, CloudWatch metrics, and any recent deployment events are much more useful before the instance is recycled.

aws ec2 get-console-output \
  --instance-id i-1234567890abcdef0 \
  --latest

You should also check the status-check metrics around the failure window:

1aws cloudwatch get-metric-statistics \
2  --namespace AWS/EC2 \
3  --metric-name StatusCheckFailed \
4  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
5  --start-time 2026-03-07T00:00:00Z \
6  --end-time 2026-03-07T01:00:00Z \
7  --period 60 \
8  --statistics Maximum

Even a few minutes of evidence collection helps later when you need to explain what happened or prevent a repeat.

What to Do for an Instance Check Failure

Instance check failures usually point to guest-side problems. Common causes include failed startup services, disk exhaustion, bad network configuration, or kernel-level problems after an update.

A reboot is often the first recovery step:

aws ec2 reboot-instances --instance-ids i-1234567890abcdef0

If that does not help, use the EC2 serial console if available, or detach the root EBS volume and inspect it from a rescue instance. That offline repair path is especially useful when the instance never reaches a usable network state.

What to Do for a System Check Failure

System check failures are different. They usually indicate trouble on the AWS host side rather than inside your operating system. In that case, waiting briefly or performing a stop-start cycle is often more appropriate than repeatedly debugging the guest.

Be careful with stop-start actions, because they can change the public IP address if the instance is not using an Elastic IP. They also reset instance-store-backed data. That means the remediation step itself can create a second incident if you do not verify the networking and storage assumptions first.

Build the Environment So One Instance Does Not Matter

The real fix for many 1/2 checks passed incidents is architectural rather than operational. Critical services should not depend on one manually repaired instance. Load balancers, Auto Scaling groups, health-check alarms, and immutable instance replacement all reduce the impact of a single-host failure.

At minimum, set alarms on status-check metrics and attach runbook links to the alerting path. If the on-call engineer has to search documentation while the instance is unhealthy, your incident process is already slower than it should be.

A Small Runbook Pattern Helps

Even a short shell snippet can standardize the first response:

1INSTANCE_ID=i-1234567890abcdef0
2
3aws ec2 describe-instance-status --instance-ids "$INSTANCE_ID" --include-all-instances
4aws ec2 get-console-output --instance-id "$INSTANCE_ID" --latest

The goal is not to automate every decision. The goal is to ensure the first evidence-collection steps happen consistently before someone starts clicking reboot out of habit.

Common Pitfalls

The biggest mistake is treating every 1/2 checks passed event the same way. Another is rebooting first and losing useful diagnostic context. Teams also forget that a stop-start cycle can change networking details, or they run important workloads on standalone instances without replacement capacity and then turn a routine host problem into an outage.

Summary

• '1/2 checks passed means one EC2 health domain is failing.'
• Identify whether the failed check is system-level or instance-level first.
• Collect metrics and console evidence before disruptive recovery actions.
• Reboot is usually for guest-side failures; stop-start is more relevant for host-side failures.
• Long-term resilience comes from redundancy and replacement patterns, not heroic manual repair.