How to Check AWS Status: Server Status Pages & Real-Time Monitoring

When AWS has a bad day, a significant portion of the internet goes with it. Amazon Web Services holds approximately 30% of the global cloud infrastructure market — S3 stores over 350 trillion objects, Lambda handles millions of invocations per second, and services from Slack to Netflix depend on AWS regions staying online. So when something breaks, the first question every engineering team asks is the same: is AWS down, or is it just us?

Answering that question is harder than it should be. The official AWS status page has a documented history of delayed updates, partial reporting, and outright gaps where major incidents went unreported for hours. If your monitoring strategy starts and ends with refreshing health.aws.amazon.com, you're going to find out about outages after your users do. This guide covers every reliable method for checking AWS status — and how to build a monitoring setup that tells you about problems before Amazon acknowledges them.

The Official AWS Health Dashboard: What It Shows (and Doesn't)

AWS provides two status interfaces. The AWS Health Dashboard — Service health at health.aws.amazon.com/health/status is the public-facing page that shows the operational status of every AWS service across every region. It's the first place most developers check. The AWS Health Dashboard — Your account health, accessible after signing into the AWS Console, shows events that specifically affect resources in your account — scheduled maintenance, service degradations impacting your instances, and region-specific issues for services you actually use.

The public dashboard uses a color-coded table: green for operational, yellow for performance issues, red for service disruption. Each service in each region gets its own row. Clicking an event shows a timeline with updates from the AWS operations team. In theory, this gives you everything you need. In practice, the updates often lag behind reality by 30 minutes to several hours.

The account-specific health view is more useful for targeted issues — your EC2 instance is scheduled for hardware maintenance, your RDS instance is affected by a regional degradation, that sort of thing. It also feeds into Amazon EventBridge (available to all accounts at no cost), so you can trigger Lambda functions or SNS notifications based on health events. But it still depends on AWS detecting and reporting the issue internally before it surfaces in your dashboard.

Why the AWS Status Page Is Unreliable During Major Outages

The most infamous example is the February 2017 S3 outage in us-east-1. A mistyped command during routine maintenance took down a massive chunk of S3, which cascaded into failures across dozens of dependent services. The outage lasted about four hours. The AWS Service Health Dashboard? It showed green checkmarks for most of that window. The status indicator icons were stored on S3 itself, so the dashboard couldn't display outage states because the infrastructure it depended on was the thing that had broken. AWS later moved the dashboard to run across multiple regions, but the fundamental problem remains: the status page is a lagging indicator.

December 2021 drove the point home with three separate outages in a single month. On December 7, a network device impairment in us-east-1 knocked out services for five to seven hours, affecting Disney+, Netflix, Ring, Alexa, and Amazon's own retail logistics. External monitoring tools like Catchpoint detected the issue at 10:33 AM ET — the AWS Health Dashboard wasn't updated until 12:37 PM ET, over two hours later. On December 15, a separate incident in us-west-1 and us-west-2 caused by network congestion took down Slack, Okta, and Zoom for about an hour. Then on December 22, a data center power loss in us-east-1 affected Slack, Imgur, and Fortnite, with some customers experiencing residual issues for up to 17 hours. The November 2020 Kinesis outage in us-east-1 followed the same pattern — widespread impact cascading across over twenty dependent services, and even the ability to post updates to the status page was impaired.

This isn't a knock on AWS operations. Large-scale distributed systems are genuinely difficult to diagnose in real time, and confirming root causes takes longer than noticing symptoms. But it means your team can't rely on the status page as a primary alerting mechanism. By the time the dashboard turns red, your customers have already been affected for 20 minutes to several hours.

Five Ways to Check AWS Status Independently

1. Monitor Your Own Endpoints

The most reliable signal that AWS is affecting you is your own application's behavior. If your API response times spike from 200ms to 5 seconds, or your health check starts returning 503s, you know immediately — regardless of what any status page says. Set up external monitoring that pings your endpoints from multiple geographic locations every 60 seconds. If your app runs on us-east-1 and checks from Europe and Asia both start failing, the problem is almost certainly infrastructure, not your code.

The PinusX Monitor handles exactly this. Create monitors for your critical endpoints, set 1-minute check intervals, and get Slack alerts when response times degrade or endpoints go down. If three consecutive checks fail, PinusX flags an incident automatically — often before AWS updates their own status page.

2. Watch AWS CloudWatch Metrics

CloudWatch is AWS's native monitoring service, and it can detect regional issues before the public health dashboard updates. Key metrics to watch:

• Lambda invocation errors and duration — sudden spikes in duration or error rate indicate infrastructure strain.
• ELB 5xx error counts — a jump in 502/503 errors from your load balancer points to unhealthy targets, often caused by underlying AWS issues.
• RDS read/write latency — database latency spikes during regional network issues.
• SQS approximate age of oldest message — if messages stop being processed, something downstream is broken.

Set CloudWatch Alarms on these metrics with tight thresholds. A Lambda duration alarm at 2x your baseline will fire minutes before you notice the problem manually.

3. Follow Real-Time Community Reports

When AWS services degrade, developers report it on social media faster than any official channel. Monitoring these sources during a suspected outage gives you real-time confirmation:

• Downdetector (downdetector.com/status/aws-amazon-web-services/) — aggregates user-submitted outage reports. Spikes in the graph correlate closely with actual incidents.
• X/Twitter search — search for "AWS down" or "us-east-1" during suspected outages. The signal-to-noise ratio is surprisingly high because developers report specific services and regions.
• Hacker News — major AWS outages reliably hit the front page within 15 minutes.

4. Use the AWS Health API Programmatically

Instead of refreshing a webpage, query the AWS Health API directly. This is the same data that powers the account-specific Health Dashboard, but you can pipe it into your own alerting systems. Note: the Health API requires a Business Support+, Enterprise, or Unified Operations plan. If you're on a Basic plan, you can still receive health events at no cost through Amazon EventBridge — see the cross-region health checks section below for an EventBridge-based alternative.

# List active events affecting your account (requires Business Support+ or higher)
aws health describe-events \
  --filter "eventStatusCodes=open,upcoming" \
  --region us-east-1
# Get details for a specific event
aws health describe-event-details \
  --event-arns "arn:aws:health:us-east-1::event/EC2/..."
# List affected resources
aws health describe-affected-entities \
  --filter "eventArns=arn:aws:health:..."

Pair this with a Lambda function on a 5-minute EventBridge schedule, and you'll get automated Slack notifications whenever AWS reports an event that touches your account's resources. This catches account-specific issues (scheduled maintenance, hardware degradation) that the public dashboard doesn't surface at all.

5. Cross-Region Health Checks

If you run infrastructure in multiple AWS regions, use each region to monitor the others. A Lambda function in eu-west-1 that pings your us-east-1 endpoints provides a genuine external perspective — it's not affected by the same regional failure. When both your European and Asian monitoring agree that your US endpoint is down, you have strong evidence of a regional issue. For teams on Basic Support plans, you can combine cross-region Lambda health checks with EventBridge rules (free for all accounts) to build automated alerting without needing the Health API.

Building a Status Page for Your Own Services

When AWS has an outage, your users don't care whether the root cause is S3 or DynamoDB or a network partition in us-east-1. They care whether your service works. A public status page for your own application gives customers a single place to check — and shows them you're aware of the problem before they open a support ticket.

The PinusX Status Page Builder lets you create branded status pages that reflect the actual state of your monitors. When your uptime checks detect a failure, the status page updates automatically. No manual intervention required. Your customers see real-time status instead of waiting for you to post an update to Twitter 30 minutes after the outage started.

A good status page should include individual component status (API, web app, database, third-party integrations), a historical uptime percentage, and an incident timeline with updates. The PinusX Status Directory provides public discovery for your status page, making it accessible to anyone who searches for your service's operational status.

The Multi-Layered Monitoring Strategy

Relying on a single data source for AWS status is the mistake that catches most teams. Build layers:

1. Layer 1: External uptime monitoring. Check your own endpoints from outside AWS every 60 seconds. This is your fastest signal. PinusX Monitor covers this with automatic incident detection after 3 consecutive failures.
2. Layer 2: CloudWatch Alarms. Monitor internal AWS metrics (Lambda errors, ELB 5xx, RDS latency) with tight thresholds. These catch service-specific degradations that don't fully take down your endpoints.
3. Layer 3: AWS Health API or EventBridge integration. Automated queries for account-specific events. Catches scheduled maintenance and regional advisories. The Health API requires a paid support plan; EventBridge health event rules are available to all accounts.
4. Layer 4: Community signals. Downdetector and social media as confirmation during ambiguous situations where your monitoring shows issues but you're not sure if it's you or AWS.
5. Layer 5: The official AWS Health Dashboard. Check it last. It's useful for root cause details and resolution timelines after AWS acknowledges the issue, but it shouldn't be your first alert.

Responding to AWS Outages: A Quick Playbook

When your monitoring fires and you suspect an AWS issue:

1. Confirm the scope. Is it one service, one region, or widespread? Check your monitoring across regions. Cross-reference with Downdetector and the AWS Health API.
2. Communicate immediately. Update your status page. Don't wait for AWS to confirm — tell your users what you know: "We're experiencing degraded performance. We're investigating and will update within 15 minutes."
3. Activate your failover if you have multi-region infrastructure. Route traffic away from the affected region using Route 53 health checks or your CDN's failover rules.
4. Monitor recovery. AWS outages often recover in waves — some services come back before others. Don't declare "all clear" until your monitoring confirms stable performance for at least 15 minutes.
5. Conduct a postmortem. Even if the root cause was AWS, review how long it took you to detect the issue, communicate to users, and (if applicable) fail over. That's the gap you can close.

AWS publishes detailed post-incident summaries for major outages at aws.amazon.com/premiumsupport/technology/pes/. Read them — they're some of the best distributed systems failure analysis available publicly. Understanding what broke and why helps you build more resilient architectures.

Stop Refreshing the Status Page

The AWS status page is a useful reference, not a monitoring tool. It confirms what happened after the fact. It doesn't warn you before your users notice. Build your monitoring stack so that the status page is the last thing you check, not the first — because by the time it turns red, you should already be well into your incident response.

Start monitoring your endpoints today with PinusX Monitor — set up 60-second health checks, get Slack alerts on failures, and build a public status page so your customers always know where things stand. When the next AWS outage hits, you'll know about it before Amazon does.

Frequently Asked Questions