AWS Health Dashboard

The AWS Health Dashboard tells you when AWS itself is having problems — and, more importantly, when those problems are touching your specific resources. There are two layers to it: a public page that shows the overall status of every AWS service, and a private, account-scoped view (the Personal Health Dashboard) that flags scheduled maintenance, planned deprecations, and instance retirements aimed directly at the resources you own. If you only watch the public page, you will miss the events that actually matter to you. This page shows you how it works and, crucially, how to automate alerts off the events scoped to your account.

Two dashboards, two very different purposes

People say “the AWS status page” as if there is one thing. There are really two, and confusing them is the most common mistake.

	Service Health Dashboard (public)	Personal Health Dashboard (your account)
Scope	All AWS services, all customers, globally	Only events affecting your resources
Who sees it	Anyone, no login	You, signed into your account
What it shows	Region-wide service outages and degradations	Scheduled maintenance, instance retirements, deprecations, account-specific issues
Authoritative for “is my stuff affected?”	No	Yes
Automation hook	None	Amazon EventBridge events

The Service Health Dashboard is the green/yellow/red grid you check during a suspected outage. It is honest but blunt: AWS only marks a service “degraded” once an issue is broad enough to warrant a public statement.

The Personal Health Dashboard (PHD for short) is the part engineers underuse. It surfaces events tied to your account: “EC2 (Elastic Compute Cloud, AWS virtual servers) instance i-0a1b2c3d4e5f is scheduled for retirement on 2026-07-01”, “RDS (Relational Database Service) maintenance window applies to your database”, or “you are using a TLS version that AWS is deprecating”.

Gotcha: The public status page often looks all-green while a problem is still hitting your account. AWS may be working a localized issue that affects a slice of customers but isn’t yet a public incident. The Personal Health Dashboard — and the EventBridge events it emits — is the authoritative source for what is actually touching your resources. Automate alerts off the PHD, never off the public page.

When to use this (and when not to)

Use the Personal Health Dashboard when you need to know about anything AWS is doing to your infrastructure: maintenance reboots, hardware retirements, certificate or API deprecations, and account-specific service events. Treat it as a primary input to your operations runbook.

Do not use it as your application monitoring tool. PHD tells you when AWS is the cause; it says nothing about your own bugs, your CPU spikes, or your failed deployments. For that you want CloudWatch metrics and alarms. The two are complementary: CloudWatch watches your workload, AWS Health watches the platform under it.

Viewing your events in the console

1. Sign in to the AWS Management Console.
2. Open AWS Health Dashboard (search “Health” in the top search bar, or go to the Health service).
3. In the left menu choose Your account health to see the Personal Health Dashboard.
4. Review the three tabs:
   • Open and recent issues — active or recently resolved problems affecting you.
   • Scheduled changes — upcoming maintenance, retirements, and deprecations.
   • Other notifications — informational items like deprecation reminders.
5. Click any event to see the affected resources (e.g. specific instance IDs) and the recommended action.

Reading events from the AWS CLI

The AWS Health API is available through the AWS CLI v2. Note that the Health API requires an active Business, Enterprise On-Ramp, or Enterprise Support plan — it is not available on the free Basic or Developer support tiers.

List recent events that affect your account:

aws health describe-events \
  --filter "eventStatusCodes=open,upcoming" \
  --region us-east-1

Output:

{
    "events": [
        {
            "arn": "arn:aws:health:us-east-1::event/EC2/AWS_EC2_INSTANCE_RETIREMENT/AWS_EC2_INSTANCE_RETIREMENT_abc123",
            "service": "EC2",
            "eventTypeCode": "AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED",
            "eventTypeCategory": "scheduledChange",
            "region": "us-east-1",
            "startTime": "2026-07-01T08:00:00-07:00",
            "statusCode": "upcoming"
        }
    ]
}

Note: The Health API is global but you must call its single endpoint in us-east-1 (for the main partition). Pointing the CLI at another Region for this call will fail.

To see exactly which of your resources an event hits:

aws health describe-affected-entities \
  --filter "eventArns=arn:aws:health:us-east-1::event/EC2/AWS_EC2_INSTANCE_RETIREMENT/AWS_EC2_INSTANCE_RETIREMENT_abc123" \
  --region us-east-1

Output:

{
    "entities": [
        {
            "entityArn": "arn:aws:health:us-east-1::entity/abc123",
            "entityValue": "i-0a1b2c3d4e5f",
            "statusCode": "IMPAIRED"
        }
    ]
}

Automating alerts with EventBridge

Polling the dashboard by hand does not scale. The right pattern is to react to AWS Health events automatically through Amazon EventBridge (the event bus that routes AWS events to targets like SNS, Lambda, or Slack). Health publishes every PHD event to EventBridge with the source aws.health, so you can match and route them in real time. This works on any support tier — the EventBridge integration does not require a paid plan, unlike the Health API.

Create a rule that catches scheduled changes and instance retirements, then pushes them to an SNS (Simple Notification Service) topic that emails your on-call channel.

Resources:
  HealthAlertTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: aws-health-alerts

  HealthEventRule:
    Type: AWS::Events::Rule
    Properties:
      Description: Forward AWS Health events affecting our resources
      EventPattern:
        source:
          - aws.health
        detail-type:
          - "AWS Health Event"
        detail:
          eventTypeCategory:
            - scheduledChange
            - issue
      State: ENABLED
      Targets:
        - Arn: !Ref HealthAlertTopic
          Id: HealthToSns

The equivalent with the AWS CLI:

aws events put-rule \
  --name aws-health-alerts \
  --event-pattern '{"source":["aws.health"],"detail-type":["AWS Health Event"]}' \
  --region us-east-1

Output:

{
    "RuleArn": "arn:aws:events:us-east-1:111122223333:rule/aws-health-alerts"
}

Once the rule fires, a Lambda target can parse detail.affectedEntities and, for example, automatically stop and start an instance ahead of a scheduled retirement, or open a ticket in your issue tracker.

Cost note: AWS Health events delivered to EventBridge are free to receive. You only pay for the downstream targets you invoke — SNS notifications (the first 1,000 email notifications per month are free, then about $2 per 100,000) and any Lambda execution. For practical alerting volumes this is effectively free.

Best practices

• Treat the Personal Health Dashboard as the source of truth for “is AWS affecting my resources?” — not the public status page, which can lag or stay green.
• Automate, do not poll. Wire aws.health EventBridge events to SNS, Slack, or a ticketing system so nobody has to remember to check a dashboard.
• Act on scheduled changes early. Instance retirements and maintenance windows come with notice; use that window to migrate or reschedule rather than getting surprised at reboot time.
• Route by category. Send issue events to your incident channel and scheduledChange events to a planning queue so urgent and non-urgent items don’t blur together.
• Use an organization-wide view. With AWS Organizations, enable the Health Organizational View so a central account sees events across every member account in one place.
• Pair Health with CloudWatch. Health tells you when AWS is the cause; CloudWatch alarms tell you when your application is. You need both for a complete picture.

Related Topics

• What is CloudWatch?
• CloudWatch alarms
• EventBridge for monitoring
• AWS CloudTrail
• CloudWatch dashboards