Your AWS resources went down at 2 AM. Is it your code, your configuration, or AWS itself? Knowing the difference matters because troubleshooting the wrong layer wastes hours you don’t have. AWS provides three built-in tools that show service health in real time, but most teams don’t know where to find them or how they work differently. This guide walks through the exact steps to check AWS service status using the Service Health Dashboard, Personal Health Dashboard, and programmatic access methods so you can quickly rule out platform issues and focus your troubleshooting where it counts.

AWS Service Health Status: Quick Check Methods

AWS service health indicators use a simple color system. Green means operational, yellow signals performance degradation, and red indicates a service outage. When you access the dashboard, these indicators appear next to each service name, letting you spot problems in seconds. The Current Status section updates automatically, so the information stays current as situations develop.

You can reach the AWS Service Health Dashboard through two methods. Type “Health” into the search box at the top of the AWS console, or navigate directly to http://status.aws.amazon.com in any browser. The dashboard isn’t listed in the standard services menu, which is why many AWS users don’t know it exists.

Here’s the exact sequence for accessing the dashboard through the AWS console:

1. Log into the AWS Management Console using your credentials
2. Click the search box at the top of the page and type “Health”
3. Select “AWS Health Dashboard” from the search results
4. The Service Health Dashboard opens, displaying current service status across all regions

The Status History section sits below the Current Status area and displays service problems from recent days. This view helps you determine whether an issue you experienced was part of a broader AWS incident. The dashboard refreshes every one to two minutes without requiring manual page reloads, keeping the information current as AWS updates service status.

The Current Status section organizes all AWS services by region. Services like EC2, S3, RDS, Lambda, and dozens of others appear in the list. Each service shows its health indicator for every region where it operates, so you can quickly identify whether a problem affects only specific geographic areas or spans multiple regions.

Personal Health Dashboard for Account-Specific Service Events

The Personal Health Dashboard differs from the Service Health Dashboard by showing only events that affect resources in your specific AWS account. While the Service Health Dashboard displays the status of all AWS services globally, the Personal Health Dashboard filters that information to show what matters to your infrastructure.

Access the Personal Health Dashboard by clicking the yellow button labeled “Open Personal Health Dashboard” from the Service Health Dashboard page. The dashboard organizes information across three tabs, each serving a different monitoring purpose. Open issues appear in the first tab. Scheduled maintenance and changes appear in the second. General notifications from AWS appear in the third. All tabs display events from the past 90 days, giving you a substantial historical view of account-specific activity.

The event list displays five key details for each entry. Event name describing the issue. Affected region. Start time when the event began. Last update time showing when AWS most recently modified the event status. A count of affected resources in your account. Filter options sit above the event list, letting you narrow results by Start Time, availability zone, specific service, or region. When you need an unfiltered view of all events, click the “See All Issues” link to access the complete Event Log with every recorded event.

Programmatic Access: CLI, SDK, and API Implementation

The AWS Health API functions as a RESTful service that communicates over HTTP and returns data in JSON format. Three programmatic methods exist for accessing health information. The AWS Command Line Interface (CLI), Software Development Kits like Boto3 for Python, and direct API calls using HTTP requests. Each method requires proper request signing and authentication to verify your identity and permissions.

IAM permissions control access to AWS Health data through all three methods. Your IAM user or role needs the health:Describe* permission to read health events, and health:List* permission to list available events. Add these permissions to an IAM policy attached to the user or role that’ll run your health check commands or scripts. Without proper IAM configuration, API calls return authentication errors even when your credentials are valid.

AWS CLI Commands for Health Monitoring

The AWS CLI provides commands that query health information and return results in JSON format. Run aws health describe-events to retrieve service health events, adding filters to narrow results by time range, service, or region. The JSON output contains event details including ARN (Amazon Resource Name), service name, event type code, region, start time, and status.

Common AWS Health CLI commands include:

• aws health describe-events retrieves a list of health events based on specified filters
• aws health describe-event-details returns detailed information about specific events using event ARNs
• aws health describe-affected-entities lists AWS resources affected by specific health events
• aws health describe-event-aggregates provides counts of health events grouped by service or region
• aws health describe-event-types returns available event type codes for filtering queries

SDK Implementation with Boto3

Python developers commonly use Boto3 to interact with AWS Health programmatically. After installing Boto3 with pip install boto3, create a client with client = boto3.client('health', region_name='us-east-1'), then call response = client.describe_events() to retrieve health events. The response object contains a list of events under response['events'], which you can iterate through to extract event details. Common API operations include describe_events() for listing events, describe_event_details() for detailed event information, and describe_affected_entities() for finding affected resources. Wrap API calls in try except blocks to handle ClientError exceptions, which occur when authentication fails, rate limits are exceeded, or invalid parameters are passed.

Rate limiting applies to all AWS Health API methods. Different limits for different operations. The describe_events operation allows 10 requests per second, while describe_event_details permits 10 requests per second for up to 10 events per request. Build retry logic into automated health checks using exponential backoff when rate limit errors occur, and cache results when checking health status more frequently than every minute.

Regional and Service-Specific Issue Detection

The Service Health Dashboard serves as the primary starting point when troubleshooting potential AWS service problems. Before diving into application logs or infrastructure configuration, check whether AWS has reported issues affecting your region or services. This approach saves troubleshooting time by quickly ruling out (or confirming) AWS side problems.

The service history feature displays all AWS service interruptions from the past year, accessible through the Status History section of the dashboard. Filter this historical view by Service (selecting from the dropdown list of AWS services), AWS Region (choosing specific geographic locations), and date range (using the calendar selector). This filtering capability helps you investigate whether intermittent problems correlate with documented AWS service disruptions.

Event severity falls into two categories. Informational and Degradation. Informational events announce scheduled maintenance, service launches, or operational notifications that don’t indicate current problems. Degradation events signal active issues reducing service performance or availability. When assessing impact, prioritize Degradation events affecting services and regions your application uses, and check whether the event’s start time aligns with when your problems began.

Click the “See All Issues” link to access the unfiltered Event Log. Every recorded event displays without default filters. Select individual events to view detailed information across three sections. Status (showing current state and whether the issue’s resolved), timeline (listing each update AWS posted with timestamps), and affected resources (displaying which availability zones or specific resource types are impacted). Cross reference the affected resources with your infrastructure to determine whether your deployments sit in impacted zones.

During an AWS Sydney Region service disruption, monitoring systems detected EC2 servers in one availability zone becoming unavailable while CPU utilization increased on servers in a different availability zone as they handled additional load. AWS reported connectivity issues for the AP-Southeast-2 region during the same timeframe. “Amazon EC2 and RDS instances in a single Availability Zone in the Asia Pacific (Sydney) Region are experiencing connectivity issues due to cooling failure in one data center.” This example demonstrates how regional filtering and service-specific event details reveal the scope of an incident and help correlate your monitoring data with AWS reported issues.

When detecting AWS service health issues, follow these troubleshooting steps:

• Verify the affected region matches where your resources are deployed
• Check whether the affected service’s one your application depends on
• Review the event timeline to see when AWS first reported the issue and posted updates
• Identify affected availability zones and compare them to your resource locations
• Assess event severity to determine whether the issue explains your observed problems
• Monitor the event for status updates and estimated resolution time

Automated Monitoring, Alerts, and Notification Systems

Automated health monitoring eliminates the need for manual dashboard checks by pushing alerts when AWS reports service issues. Multiple notification methods exist, each serving different use cases. CloudWatch and EventBridge for AWS native automation, RSS feeds for external systems, and scheduled maintenance views for planning. Combining these methods creates a comprehensive awareness system that catches issues through multiple channels.

CloudWatch and EventBridge Integration

CloudWatch custom dashboards display health metrics alongside other monitoring data, creating unified views of AWS infrastructure status. Build dashboards showing health event counts, affected resource counts, and timeline visualizations of recent incidents. Share dashboards three ways. Restricted sharing requires recipient email addresses and passwords (keeping sensitive data private), public sharing generates a link anyone can access without credentials (useful for status pages), or SSO integration provides automatic access to all dashboards for authenticated users in your organization.

EventBridge rules trigger actions when AWS Health events occur, enabling automated responses to service issues. Create rules that match specific event patterns, then configure targets like SNS topics that send email alerts to operations teams. Set up an SNS topic with email subscriptions, create an EventBridge rule matching AWS Health events, and add the SNS topic as a target. The rule evaluates every AWS Health event against your pattern, triggering notifications when matches occur.

Common EventBridge rule patterns for AWS Health monitoring include:

• Service-specific events: {"source": ["aws.health"], "detail": {"service": ["EC2"]}} triggers only for EC2 service events
• Regional events: {"source": ["aws.health"], "detail": {"region": ["us-east-1"]}} matches events in specific regions
• Severity filtering: {"source": ["aws.health"], "detail": {"eventTypeCategory": ["issue"]}} alerts only on active issues, not informational events
• Scheduled maintenance: {"source": ["aws.health"], "detail": {"eventTypeCategory": ["scheduledChange"]}} triggers for planned maintenance notifications
• Account-specific events: {"source": ["aws.health"], "detail-type": ["AWS Health Event"]} matches all events affecting your account resources

RSS Feed Subscriptions and External Monitoring

AWS publishes RSS feeds for real-time service status updates, accessible at region-specific URLs following the pattern https://status.aws.amazon.com/rss/region.rss (replacing “region” with identifiers like “us-east-1” or “eu-west-1”). Subscribe to these feeds using RSS readers or custom scripts that parse feed content. Configure feeds to monitor only services and regions relevant to your infrastructure by filtering feed items based on service names in item titles or descriptions.

Script Eventsources parse RSS feeds and trigger alerts when AWS posts new service issues. Each alert generated from RSS parsing includes three components. The timestamp from when AWS posted the RSS feed item, the message content describing the service issue, and a link back to the original RSS post for additional details. Build filters that exclude or include specific AWS services and regions by checking item content against whitelists or blacklists before generating alerts. This filtering prevents alert fatigue by ensuring notifications match your operational concerns.

Scheduled Maintenance and Change Notifications

The Scheduled Changes tab in the Personal Health Dashboard displays upcoming maintenance events affecting your account resources, typically showing items planned for the next seven days. Review this tab weekly to prepare for maintenance windows that might impact availability or require coordination with your team. Scheduled maintenance events often include information about expected duration, affected services, and whether any action’s required on your part.

Configure notification preferences for different event types through the AWS Health settings page, specifying which categories warrant immediate alerts versus daily digest emails. Mobile notifications push critical alerts to smartphones, ensuring on call teams receive urgent notices even away from computers. Email notifications can be customized by event category, letting you route scheduled maintenance to planning teams while sending active issues to operations teams.

Common scheduled maintenance event types include:

• Database engine updates for RDS instances requiring brief downtime
• EC2 instance retirement notifications when physical hosts require maintenance
• Security patching for managed services like Elastic Beanstalk or ECS
• Network infrastructure maintenance affecting connectivity in specific availability zones

Combine multiple notification methods for comprehensive coverage and redundancy. Configure EventBridge rules for immediate alerts on critical services, subscribe to RSS feeds for monitoring system integration, enable email notifications for scheduled maintenance planning, and review the Personal Health Dashboard weekly for comprehensive awareness. Add automated remediation actions to EventBridge rules, like Lambda functions that failover to backup regions when health events indicate regional problems. This multi-layered approach ensures you learn about AWS issues through multiple paths, reducing the chance that a single notification failure leaves you unaware of service problems.

Third-Party Integration Options for Enhanced Monitoring

Third party integration centralizes AWS Health monitoring alongside alerts from applications, infrastructure, and external services. Instead of checking multiple dashboards, teams view unified incident timelines showing how AWS service issues correlate with application performance degradation. This unified view speeds troubleshooting by making connections that aren’t visible when monitoring systems operate in silos.

DataDog integration for AWS Health combines service health events with infrastructure metrics, application performance monitoring, and log data in a single platform. Configure the DataDog AWS integration to collect Health API events automatically, then build monitors that trigger when specific health event types appear. Create dashboards showing AWS Health status alongside EC2 CPU utilization, RDS query performance, and application error rates. When an AWS health event occurs, DataDog correlates the timing with changes in your metrics, often revealing that application issues started moments after AWS reported service degradation.

Slack notification setup brings AWS Health events directly into team communication channels, ensuring engineers see alerts without switching contexts. Use AWS Chatbot to connect EventBridge rules to Slack channels, or build Lambda functions that parse health events and post formatted messages to Slack webhooks. Include event severity, affected services, impacted regions, and links to the AWS Health Dashboard in each message. Configure separate channels for critical issues and scheduled maintenance to prevent alert fatigue while keeping teams informed.

Custom webhook integration works for proprietary monitoring systems or platforms without pre-built AWS integrations. Create Lambda functions that trigger on AWS Health events through EventBridge, format event data as required by your monitoring platform, and POST the data to webhook endpoints. This approach works with any system accepting HTTP requests, from custom internal dashboards to specialized incident management platforms.

Multi-Account Health Monitoring with AWS Organizations

AWS Organizations integration aggregates health events across every account in your organization, eliminating the need to check each account individually. Enterprise customers running dozens or hundreds of AWS accounts benefit from this centralized view, which surfaces issues affecting any account in the organization. Without this integration, teams might miss events affecting development accounts, testing environments, or subsidiary company accounts.

Event aggregation collects health events from all member accounts and displays them in the organization’s management account. The Personal Health Dashboard presents information in three categories when Organizations integration’s enabled. General Service Events show public AWS service status affecting any customer. Your Account Events display issues specific to the management account’s resources. Organization Events list problems affecting resources in any member account. This categorization helps you quickly distinguish between widespread AWS issues and problems limited to your organization’s infrastructure.

Configure organizational health monitoring with these steps:

1. Enable AWS Health organizational view in the AWS Organizations management account through the AWS Health console
2. Grant the management account permission to aggregate health events by accepting the organizational view terms
3. Verify that member accounts appear in the organizational view by checking the Account Status section
4. Configure EventBridge rules in the management account to trigger on organization-wide health events

Cross account visibility reveals patterns invisible when monitoring accounts in isolation. When multiple accounts experience EC2 instance retirement events in the same availability zone, organizational view shows this correlation immediately. Without aggregation, each account owner sees only their own retirement notices, missing the signal that an entire availability zone requires attention. Centralized monitoring also enables consistent notification policies across all accounts, ensuring every team receives alerts through the same channels with the same thresholds.

Historical Data Analysis and Reliability Assessment

Historical health data reveals service reliability patterns that inform architectural decisions and capacity planning. Reviewing past events helps you understand how often specific services experience issues, whether problems cluster around certain times (like after major AWS announcements), and which regions demonstrate better stability records. This analysis transforms reactive troubleshooting into proactive infrastructure planning.

The service history feature maintains records of all AWS service interruptions from the past year, accessible through the Status History section. Select services and regions matching your infrastructure, then set date ranges covering the evaluation period. Export or document incidents affecting services critical to your application, noting incident duration, affected regions, and AWS’s root cause descriptions when provided. Calculate availability percentages by comparing total operational time against incident duration, revealing which services consistently meet AWS’s published SLA targets and which fall short.

Pattern identification methodology involves grouping incidents by characteristics. Service type, region, time of day, day of week, and proximity to AWS re:Invent or other major events. Some patterns indicate architectural risks. If EC2 incidents consistently affect us-east-1, multi-region deployment becomes more compelling. Other patterns reveal external factors. Maintenance events often cluster on Tuesday and Wednesday nights when fewer customers are actively using services. Document these patterns in architecture decision records, referencing them when teams debate deployment strategies or disaster recovery investments.

Reliability assessment techniques compare AWS service history against your application’s availability requirements. When your SLA promises 99.9% uptime (allowing 43 minutes of downtime monthly), check whether dependent AWS services maintained better availability over the past year. If S3 in your primary region experienced three hours of degradation across 12 months, your architecture requires failover capabilities or risk missing SLA targets. Use historical incident frequency to set realistic availability goals and determine whether single region deployments carry acceptable risk.

Final Words

Checking AWS service health doesn’t have to be complicated. Use the Service Health Dashboard for quick status checks, set up Personal Health Dashboard for account-specific alerts, or automate monitoring through CLI commands and EventBridge rules.

For enterprise teams, AWS Organizations integration provides centralized visibility across multiple accounts. Pair that with CloudWatch metrics and SNS notifications for proactive incident response.

Start with the basics: bookmark status.aws.amazon.com and configure at least email alerts for your critical services. When you’re ready, layer in automation and third-party integrations to match your monitoring needs.

Understanding how to check AWS service health through multiple methods keeps your infrastructure reliable and your team informed before small issues become major disruptions.

FAQ

Q: How do you check the AWS health dashboard?

A: You can check the AWS health dashboard by entering “Health” into the AWS console search box or visiting the direct URL http://status.aws.amazon.com. The dashboard displays real-time service status with color-coded health indicators across all AWS regions and services.

Q: What is a Route 53 health check?

A: A Route 53 health check monitors the availability and performance of your web applications, servers, or other resources by sending automated requests at regular intervals. These checks help Route 53 route traffic only to healthy endpoints and can trigger failover actions when issues are detected.

Q: How do you check instance health in AWS?

A: You check instance health in AWS through the Personal Health Dashboard, which shows account-specific events affecting your resources including EC2 instances. You can also use CloudWatch metrics, the EC2 console status checks, or CLI commands like describe-instance-status for programmatic monitoring.

Q: What is an AWS health check?

A: An AWS health check is a monitoring feature that tracks the operational status and availability of AWS services and your specific resources. Health checks provide real-time status updates, incident notifications, scheduled maintenance alerts, and event history through the Service Health Dashboard and Personal Health Dashboard.