Reading AWS regional degradation before it reaches you

Background jobs in eu-central-1 are slow. Not failing, slow. Queue depth is creeping up a few hundred messages an hour. us-east-1 is completely healthy. The team will spend the next forty minutes on a single question: is this us, or is this AWS?

It is AWS. A regional service is degraded, the kind of degradation where requests still succeed if you retry them, just later than they should. Because the retries eventually work, the application keeps returning success. The only outward symptoms are latency and a queue that will not drain.

Why the evidence contradicts itself

A regional incident is the most expensive kind to diagnose, because half of your evidence insists everything is fine. One region is degraded; the others are not. Your global dashboards average the two and show a gentle wobble. Retries mask the failure rate, so the error graphs stay flat. And the AWS status page, conservative by design, stays green well into the event. Every instrument you would normally trust is, in this specific situation, reassuring you.

Why the team scales the wrong thing

The queue is growing, so the obvious move is more workers. More workers do not help, because the workers were never the bottleneck; the downstream service they call is slow, and adding consumers just means more of them waiting. Next comes suspicion of a recent migration, then the database, then a memory leak. Each theory takes time to rule out, and each one is plausible precisely because the problem is half-invisible.

Half your evidence says everything is fine. That is what makes a regional incident so slow to name.

What monitoring changes

The move is to stop reading the global average and start reading per region, and to put the provider’s regional status next to your own regional metrics. When "eu-central-1 latency elevated" and "AWS eu-central-1 degraded" sit on the same screen, the forty-minute question answers itself in two. The point is not to fix AWS. You cannot. It is to know, early, that there is nothing of yours to fix.

Crowswatch tracks AWS status per region and surfaces it alongside your own signals, so a regional incident is something you recognise rather than something you argue about.