Is AWS down right now?

Region and service filters on Starter and up.

The panel above shows the current state of AWS as reported on the official AWS Health Dashboard, refreshed every few minutes. Open events are grouped by region and service. Below that is a list of recent events and how long they lasted.

AWS is never "down" all at once

AWS runs dozens of regions, each with separate availability zones, and hundreds of services. A problem is usually limited to one service in one region, or sometimes one zone. So the better question is: is the AWS service I use, in the region I use, having trouble?

That is why a single green or red light for "AWS" is misleading. If you run in eu-west-1 and an event affects Lambda in us-east-1, you probably do not care. Unless, that is, something you depend on runs in us-east-1 without you knowing.

The us-east-1 effect

Some AWS features and many third-party services have dependencies in us-east-1 (N. Virginia), one of the oldest and largest regions. When it has a major event, effects can spread to services that look unrelated, including SaaS tools you use that happen to run there. If several vendors in your stack have problems at the same moment, check the us-east-1 events first.

How to tell if it is AWS or you

1. Check the AWS Health Dashboard for your region and service. Look for events in the last hour, not only open ones.
2. Check your personal AWS Health view in the console. Account-specific events, like an instance on degraded hardware, appear there and not on the public dashboard.
3. Look at the scope. If only one instance or function fails, it is more likely your resource. If a whole service fails across your accounts, suspect AWS.
4. Check CloudWatch metrics for error rates and latency from the AWS side, not just your application logs.
5. Ask whether you deployed anything recently. A config change that coincides with an AWS event is still worth reverting.

What to do during an AWS incident

• Do not panic-redeploy. Restarts during a regional event can make things worse if new instances cannot launch.
• Shift traffic if you can. Multi-region setups can fail over. Multi-AZ setups usually ride out a single-zone event.
• Tell your users. A status page note saying "a provider issue is affecting uploads" saves a pile of tickets.
• Watch the vendor updates. AWS posts updates to the event as it progresses. Recovery is often gradual, with some resources coming back before others.
• Write down times. You will want them for your own incident report and any service credit request.

Reading AWS status terms

AWS event updates usually describe impact in terms of increased error rates, higher latency or degraded performance, and name affected resources or zones. "Service is operating normally" in an update means recovery. An event can stay open for some time after the main recovery while AWS works through a backlog.

Following AWS with Outage Clock

Following "AWS" as a whole would alert you for every event in every region. Instead, on Starter and above, choose the regions and services you use, such as EC2, RDS and S3 in eu-central-1 plus IAM and Route 53, which are global. Alerts arrive in email, Slack or Teams with the region, service and the latest update text. A daily digest is available if you want fewer interruptions.

We also run our own light reachability check against AWS public endpoints, which helps flag a wide outage before the dashboard is updated.

Questions

How often is this page updated?

Every few minutes. The time of the last check is shown under the status panel.

Does this cover my specific account?

No. Account-specific events only appear in your own AWS Health view in the console.

Does Outage Clock use the AWS Health API?

No. We read the public status information that anyone can see, so you do not need to share AWS credentials.

Get AWS alerts