AWS outages are announced on the AWS Service Health Dashboard, not through email or social media
When Amazon Web Services (AWS) goes down, the only official source for when it will be back up is the AWS Service Health Dashboard. You reach it at status.aws.amazon.com. This page shows you which services are affected right now, which regions are impacted, and what AWS engineers are doing to fix the problem. It updates every few minutes during an outage.
The dashboard is organized by region — US East, Europe, Asia Pacific, and others. An outage might affect only one region or multiple ones. You can filter to see only the services your business uses, so you are not reading updates about services you do not rely on.
AWS does not announce outages through Twitter, email, or their main website first. The Service Health Dashboard is where the information lives. If you follow AWS on social media and see an outage mentioned there, the dashboard already has more detail.
Key Takeaways
- The AWS Service Health Dashboard at status.aws.amazon.com is the official source for outage information and estimated recovery times.
- Outages often affect only specific regions or services, so check which ones matter to your setup before assuming everything is down.
- During an outage, the dashboard updates every few minutes with new information about what engineers are doing and when service may return.
- You can subscribe to notifications for specific services and regions so you hear about problems affecting you without getting alerts about unrelated outages.
What the dashboard actually tells you during an outage
When a service goes down, the dashboard shows a timeline. At the top is the current status — "Investigating", "Identified", "Monitoring", or "Resolved". Below that is a list of events with timestamps showing when AWS first noticed the problem, when they identified the cause, and when they started the fix.
The dashboard does not always give you an exact time when service will return. Instead, it tells you what stage the fix is in. "Investigating" means engineers are still figuring out what broke. "Identified" means they know the problem. "Monitoring" means the fix is in place and they are watching to make sure it holds. This progression tells you how close recovery is, even without a specific time.
Some outages last minutes. Others last hours. The dashboard will not guess — if AWS does not know when service returns, the page will say so. A vague estimate is less useful than honesty about uncertainty.
How to set up notifications so you do not have to check manually
The Service Health Dashboard has a subscription feature. Click the bell icon in the top right corner. You can choose to get notified about specific services — RDS, EC2, Lambda, S3, or whichever ones you use — and specific regions. AWS will send you an email or SMS when an outage starts and when it ends.
This is more practical than checking the dashboard constantly. You will hear about problems that affect you and ignore the ones that do not. If your process runs only in US East and Europe, you do not need alerts about Asia Pacific outages.
Notifications arrive within a few minutes of a status change. They are not when ready, but they are fast enough that you will know about a major outage before your users start calling.
Why AWS does not always give you a recovery time
During an outage, AWS engineers are focused on fixing the problem, not on predicting when it will be fixed. If they guess wrong — and they often do — the wrong estimate spreads across the internet and creates panic. It is more honest to say "we are working on it" than to promise a time they might miss.
Some outages are straightforward: a server fails, they restart it, service returns in ten minutes. Others are complex: a software bug affects multiple systems, they have to roll back code, test the rollback, and gradually bring service back online. That process can take hours and the timeline changes as they learn more.
The dashboard updates as the situation becomes clearer. Check back every 15 to 30 minutes during an active outage rather than expecting a single announcement with a firm recovery time.
What to do if the dashboard is down too
Rarely, the outage is so severe that even the Service Health Dashboard becomes unreachable. In that case, AWS publishes updates on their Twitter account (@awsstatus) and their status page email list. If you subscribed to notifications, you will get an email even if the website is offline.
You can also check AWS forums and Reddit communities like r/aws, where other engineers post what they are seeing. These are not official sources, but they give you a sense of how widespread the problem is and whether it affects your region.
If you have a critical process down and need to talk to AWS directly, you can open a support case through the AWS Management Console — if you can reach it — or call AWS Support. Response time depends on your support plan. Standard support does not cover outages, but Business and Enterprise support do.
Regional outages versus service-wide outages
AWS is split into regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Singapore), and others. A single region can fail without affecting the others. If your process runs in multiple regions, an outage in one might not touch your users at all.
The dashboard shows you which regions are affected. If you see "US East (N. Virginia) — Degraded Performance" but your process runs in US West, you may have no problem. Check the specific region your infrastructure uses before you assume you are down.
Some services, like IAM (Identity and Access Management), are global and not tied to a region. If IAM goes down, it affects all regions. The dashboard will make this clear.
How long AWS outages typically last
Most AWS outages last under an hour. Some last a few minutes. Outages that stretch past four hours are rare but do happen. The longest outages in AWS history have lasted several hours and affected major services like S3 or EC2.
The length depends on what broke. A network switch that fails might be fixed in 20 minutes. A software bug that requires code review and testing might take hours. A hardware failure that requires physical repair can take longer.
During the outage, your best move is to check the dashboard every 15 to 30 minutes, keep your team informed, and have a communication plan for your users. If you have a backup region or provider, this is when you might switch traffic there — but that decision depends on your architecture and how much the outage is costing you.
Frequently Asked Questions
Can I see a history of past AWS outages?
Yes. The Service Health Dashboard has a history tab that shows outages from the past 90 days. You can see how long each one lasted, which services were affected, and what AWS said about the cause. This is useful if you are trying to understand whether a particular service is reliable for your needs.
What if I think there is an outage but the dashboard says everything is fine?
The dashboard shows AWS-wide issues, not problems with your specific account or configuration. If your process is down but the dashboard is green, the problem is likely in your code, your security group settings, or your database configuration — not in AWS infrastructure. Check your process logs and your AWS account settings before assuming it is an AWS problem.
Do I need to do anything to get service back after an outage ends?
Usually no. When AWS brings a service back online, it comes back automatically. Your process should resume working without you taking action. The exception is if the outage caused a failure in your process that needs a manual restart — for example, if a database connection pool timed out and needs to be refreshed. Check your process after the outage ends to make sure it recovered cleanly.
Is there a way to avoid AWS outages entirely?
No, but you can reduce the impact. Running your process across multiple regions means an outage in one region does not take down your whole service. Using managed services like RDS with multi-region failover means AWS handles the switchover for you. The tradeoff is cost — redundancy is more expensive than running in a single region.