Get AWS statusIs AWS having problems right now? One step, one flat answer: all_operational to branch a workflow on, the worst severity open, how many services and regions are affected, and a ready-to-send sentence. Narrow it to the regions you run in so an outage on the other side of the world does not wake anyone up. This is also the one-step check that the connection works.
List open eventsEvery event AWS currently has open, with what it is, where, how long it has been running and AWS's latest update on it. Narrow by region, by service and by severity, so a workflow can page someone for a disruption in your regions and stay quiet for an informational notice somewhere else. Ordered newest first unless you say otherwise.
Check whether a service is affectedAsk about one AWS service - 'is S3 having problems in us-east-1?' - and get a flat yes or no with the severity, the regions it is affected in and AWS's latest update. Leave the region empty to ask everywhere. The answer separates three things a single boolean would blur: the service is in an event, the service is fine, and AWS Health has never heard the name you typed - which looks identical to healthy from here, and is the one case where it should not be read that way.
Check whether a region is affectedAsk about one AWS region - 'is anything wrong in eu-west-1?' - and get a flat yes or no, the worst severity open there, every service affected in it, and AWS's latest update. This is the usual gate for a deployment or a failover workflow, because a region is what most teams actually care about. A multi-region event counts here even when AWS filed it under a different region.
List affected servicesEvery AWS service currently reported as affected, one row per service and region, worst first - the service-level view of 'what is broken right now', rather than the event-level one. A single event can name well over a hundred services, so this is what a workflow reads when it wants to compare the list against the things you run. Each row says where the service stands now and the worst it reached, so a service that has already recovered inside an open event is visibly different from one that has not.
Get an eventOne event in full: every update AWS posted on it in order, every service it names with where each stands now, and every status change during it. This is the incident timeline to post into a channel or attach to a postmortem. Takes the event_id any listing action returned, or the event's AWS ARN. Open and recent events can both be asked for.
List past eventsThe AWS events recorded over a date range - what happened last week, or since the start of the quarter. Narrow by region, service and severity the same way as the open ones. An event that began before the range and was still running inside it is included, because it was part of that period. The dashboard keeps only the recent past, so the result also says the earliest date it actually covers: a range reaching further back is unanswerable, not quiet, and the two should not look alike.
Summarize events over a periodThe reliability report in one step: how many AWS events there were over a period, how many of each severity, how long they ran in total, which was the longest, and which services and regions had the most. Written for the monthly review that would otherwise mean counting a list by hand. Narrow to the regions and the service you run on.
Amazon CloudWatchMonitoring
DigitalOcean StatusMonitoring
Amazon S3Cloud Computing
AWS LambdaCloud Computing
Amazon IAMCompliance & Security
Amazon DynamoDBDatabases
Amazon SQSCloud Computing
AWS IAM Identity CenterCompliance & Security
AWS Secrets ManagerCompliance & Security
Amazon STSCompliance & Security
