An AWS Health notice does not, by itself, establish that your application is down. Start with current AWS status, then match the notice to the service, location and resources your workload actually uses.
This guide helps you interpret a Health event. Once you have confirmed customer impact, use the broader AWS outage response checklist for communication and recovery decisions.
Public incident or account event?
AWS distinguishes public service events from events specific to an account and its resources. Public notices describe regional service availability; they are not an inventory of affected resources in your account. Source: AWS Health event scope.
If you have account access, sign in to AWS Health. Its account view includes recent issues, scheduled changes and an event log. If you cannot access the account, ask its administrator to review the notice; a public status page cannot substitute for that check. Source: getting started with AWS Health.
Check the details that narrow the scope
Open the event and compare its details with your deployment record:
| Check | Question to answer |
|---|---|
| Service | Does the failing request use this AWS service? |
| Region or Availability Zone | Does the notice name the location of the affected dependency? |
| Event scope | Is this public information or an account-specific event? |
| Affected resources | Do the listed resource identifiers match your workload? |
| Times and updates | Does the provider's interval overlap your observed errors? |
AWS documents these details and the affected-resources view in its account event guide. Its dashboard can display local time or UTC, so label the timezone when sharing a timeline. Keep account IDs and resource identifiers in your team's private incident record.
Do not infer a match from a familiar service name alone. A database in one region and a network connection in another are different dependencies. If a dependency location is unknown, record that uncertainty before attributing your application's failure to the event.
Separate scheduled work from an active failure
A scheduled change may call for preparation without indicating current downtime. Read the event's category, planned time and instructions before deciding whether it explains an error occurring now.
Compare the notice with the customer action that failed, your request logs and recent changes. A normal public status page does not rule out an account issue or a fault in your own application. Equally, a public incident in an unrelated service does not confirm a cause.
Write a statement your team can verify
An illustrative update is: Uploads are failing in our application. We are checking whether the provider notice covers the storage service and region we use. The cause is not yet confirmed.
Once you establish the match, add the event link, affected customer function and observed start time. Keep provider-reported timing separate from the start of your own errors. Do not treat the event's full duration as measured downtime for every customer.
Confirm your recovery separately
After a provider recovery update, test the failed operation and check whether queued work or retries still need attention. Verify the outcome of earlier writes before replaying them. Use your existing recovery procedure when deciding whether to restore paused traffic.
Review AWS incident history for context and follow public AWS provider updates. ServiceAlert's public provider alerts do not inspect your AWS account or replace account-specific Health notifications.