aws
The worst way to learn about an AWS outage is from an angry customer. The second worst is from the AWS status page, which frequently confirms an incident after your users have already felt it. The goal of status monitoring done right is simple: detect provider problems before your customers do, and capture the evidence you will need afterward. That takes independent monitoring, not a browser tab pointed at a dashboard.
Why the status page is not enough
The AWS Health Dashboard is a deliberate, reviewed communication channel. Posting a public "we have a problem" is a considered action, which means it lags. The classic example is the 2017 S3 outage, where the status page itself was partly broken because its status icons were served from the very region that was down. During the December 2021 event, the console and API paths teams would use to check status were themselves impaired.
The lesson repeats: the provider's status page is a lagging, sometimes self-dependent indicator. It is worth watching, but it must never be your only signal.
Watch symptoms, not announcements
The earliest, most honest alarm is your own telemetry. Before AWS posts anything, your golden signals move: error rate climbs, latency spikes, successful checkouts per minute fall off a cliff. Instrument and alert on those first. They tell you something is wrong even when you do not yet know why, and they fire on the customer's timeline, not AWS's press-release timeline.
Layer three sources so no single one is your only warning:
- Your own golden signals (error rate, latency, throughput, saturation). The earliest signal.
- Synthetic checks that exercise the real request path from outside your infrastructure.
- AWS Health API events, account-scoped notifications about issues affecting your resources, consumed programmatically rather than by refreshing a page.
Monitor from outside the blast radius
This is the rule teams get wrong most often: do not host your monitoring inside the thing you are monitoring. If you run synthetic checks from us-east-1 to watch us-east-1, a regional outage takes down your checkers along with everything else, and your dashboards go quiet exactly when you need them loudest. Run synthetic canaries from a different region or a third-party network, and make sure alert delivery does not route through the region you are watching either.
| Monitoring choice | Fragile setup | Resilient setup |
|---|---|---|
| Synthetic check location | Same region as the workload | Different region or external network |
| Primary signal | AWS status page only | Own golden signals plus Health API |
| Alert delivery | In-region email/SMS pipeline | Off-AWS paging and status channel |
| Status page hosting | On the affected infrastructure | Independent third-party host |
The same principle applies to your incident communication: host your public status page and incident channel off your own infrastructure, so you can tell customers what is happening even while your stack is down. This is a line item in the DR checklist for good reason.
Route alerts where they will actually arrive
An alert that depends on the failing region may never be delivered. Send alerts to a paging tool and a status channel hosted outside AWS, or at minimum outside the affected region. Test the delivery path the same way you test failover, because an untested alert pipeline is as much theater as an untested standby region. On average, independent detection plus instant outage alerts reaches you 20 to 40 minutes before the first customer ticket, which is often the difference between a controlled response and a scramble.
Capture evidence while it is happening
Detection has a second job beyond waking you up: building the record you will need later. During the incident, automatically log timestamps, affected endpoints, error rates, and screenshots of your own degraded behavior. That evidence powers an honest post-mortem, and it is exactly what you need to claim any SLA credits the provider owes you when an outage breaches its commitment. You can check whether a given incident qualifies at cloudslacredit.com, and the reliability research at clouddowntime.com/data shows how often AWS regions and services actually miss their marks.
Tie it back to architecture
Monitoring is not a substitute for resilience, it is the trigger for it. You cannot fail over to a second region, evacuate an AZ, or invoke a runbook for an incident you have not detected. Detection sits upstream of every recovery move in Surviving a us-east-1 outage and the DR checklist. Build the independent monitoring first, then the recovery it activates has something to fire on.
For detection wired directly into your own stack, Next Signal (sponsor) watches provider status continuously so you hear about the event from your tooling, not from a customer who found out before you did.