CloudWatch Metric Guide

AWS/EC2/StatusCheckFailedCount

StatusCheckFailedAmazon EC2 CloudWatch metric

StatusCheckFailed combines the results of both the instance status check (instance software and network configuration) and the system status check (underlying AWS host hardware). A value of 1 means at least one of these checks has failed.

What it measures

About StatusCheckFailed

StatusCheckFailed combines the results of both the instance status check (instance software and network configuration) and the system status check (underlying AWS host hardware). A value of 1 means at least one of these checks has failed.

NamespaceAWS/EC2
Metric nameStatusCheckFailed
UnitCount
AWS docsOfficial Amazon EC2 metrics reference

Why this metric matters

StatusCheckFailed = 1 is an emergency signal, not a warning. Unlike CPU or memory metrics that indicate stress, a failed status check means the instance itself has a fundamental problem — either a kernel panic, a hardware failure on the underlying host, or a network misconfiguration that makes the instance unreachable.

AWS distinguishes two types of failures: instance status failures (problems in the OS, which a reboot or user intervention can often fix) and system status failures (problems with the underlying AWS hardware, which require AWS to move the instance to a healthy host). Both types result in StatusCheckFailed = 1. Both require immediate action. Neither resolves without intervention or AWS action.

Recommended alarm threshold for StatusCheckFailed

Recommended threshold

> 0 — alarm immediately

StatusCheckFailed has no gradual scale — it is either passing (0) or failing (1) per AWS documentation. A value of 1 represents a hard infrastructure failure that must be addressed immediately (Nuberio recommendation). Set this alarm with a 1-minute evaluation period and the minimum number of evaluation periods to minimize time-to-alert. There are no false positives in a production environment — StatusCheckFailed = 1 always warrants investigation.

Is your StatusCheckFailed alarm already set up correctly?

The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including StatusCheckFailed — in 5 minutes.

Run a free audit →

Common failures that show up in StatusCheckFailed

When StatusCheckFailed reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.

  • System status check failure — the underlying AWS host hardware has failed; AWS detects this and typically migrates the instance automatically, but the migration window causes downtime

  • Kernel panic or OS crash — the instance OS has crashed; a hard reboot initiated from the EC2 console or via API is required

  • Network interface misconfiguration — a change to the instance's network interface, routing table, or security group has made the instance unreachable for health checks

  • Corrupted disk — the instance's EBS root volume has encountered I/O errors, causing the OS to mount the filesystem in read-only mode and fail status checks

  • Memory exhaustion — the instance ran out of memory, the OOM killer terminated critical OS processes, and the instance is effectively non-functional without a reboot

How the Nuberio Audit checks StatusCheckFailed

The free Audit scans every Amazon EC2 resource in your account and checks whether a StatusCheckFailed alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.

Nuberio Audit

Scans your CloudWatch setup for missing or misconfigured StatusCheckFailed alarms. Free, 5-minute read-only scan.

Run a free audit →

Related Amazon EC2 metrics

StatusCheckFailed rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon EC2 coverage.

FAQ

Frequently asked questions about StatusCheckFailed

Common questions about setting up CloudWatch alarms for StatusCheckFailed in Amazon EC2.

What is the recommended CloudWatch alarm threshold for StatusCheckFailed?+

> 0 — alarm immediately. StatusCheckFailed has no gradual scale — it is either passing (0) or failing (1) per AWS documentation. A value of 1 represents a hard infrastructure failure that must be addressed immediately (Nuberio recommendation). Set this alarm with a 1-minute evaluation period and the minimum number of evaluation periods to minimize time-to-alert. There are no false positives in a production environment — StatusCheckFailed = 1 always warrants investigation.

Which CloudWatch namespace does StatusCheckFailed belong to?+

StatusCheckFailed is published in the AWS/EC2 namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/EC2". See the Amazon EC2 CloudWatch metrics reference in the AWS documentation.

Does Nuberio automatically create CloudWatch alarms for StatusCheckFailed?+

No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon EC2 resources are missing a StatusCheckFailed alarm, then gives you the exact CLI command to create it yourself.

Can I use Nuberio without already having a StatusCheckFailed alarm set up?+

Yes. The free Audit works whether or not you have any StatusCheckFailed alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus the copy-paste AWS CLI command to create it.

This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, DynamoDB, SQS, API Gateway, S3, CloudFront, ElastiCache, and EKS. To find which Amazon EC2 alarms your account is missing — including StatusCheckFailed — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.