AWS's US-EAST-1 region had a 1 hour 1 minute stretch of increased API error rates affecting new EC2 instance launches. The fault sat with AWS, not with your own infrastructure, and it was over by the time most people would have noticed.
Started
23:26 UTC
Duration
Lasted 1h 1m
Source
IsDown
Next time
AWS (Amazon Web Services) is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Amazon CloudFront, Amazon Elastic Compute Cloud, Amazon Elastic Compute Cloud (N. Virginia), Amazon Elastic Container Service, Amazon Elastic Container Service (N. Virginia), Amazon Elastic Kubernetes Service, Amazon Elastic Kubernetes Service (N. Virginia), Amazon Elastic Load Balancing, Amazon Elastic Load Balancing (N. Virginia), Amazon Elastic MapReduce, Amazon Elastic MapReduce (N. Virginia), Amazon OpenSearch Service, Amazon OpenSearch Service (N. Virginia), Amazon SageMaker, Amazon SageMaker (N. Virginia), Amazon WorkSpaces, Amazon WorkSpaces (N. Virginia), AWS AppSync, AWS AppSync (N. Virginia), AWS DataSync, AWS DataSync (N. Virginia), AWS Global Accelerator, AWS NAT Gateway, AWS NAT Gateway (N. Virginia), AWS Site-to-Site VPN, AWS Site-to-Site VPN (N. Virginia), AWS Transit Gateway, AWS Transit Gateway (N. Virginia), AWS VPCE PrivateLink, AWS VPCE PrivateLink (N. Virginia), Traffic Mirroring, Traffic Mirroring (N. Virginia), AWS Fargate, AWS Fargate (N. Virginia)
What happened?
AWS logged one incident on this day, starting at 23:26 UTC and lasting 1h 1m. The title AWS gave it was "Increased Error Rates - N. Virginia", and its own updates narrow the fault to the EC2 launch path in US-EAST-1. The first update, at 23:26, said only that AWS was investigating increased API error rates in the region. The second, at 23:44, was more specific: elevated error rates for RunInstances, CreateFleet and related EC2 launch workflows, meaning customers trying to launch new instances could see failures or slow API responses. AWS also stated that existing instances remained unaffected, and it recommended retrying failed RunInstances and CreateFleet calls while its engineers worked on recovery. No further update was filed after that, and AWS reported it saw initial signs of recovery before the incident closed. That is two updates total, which is thin for judging the shape of the event, but it is what AWS put on the record. The component list tied to this incident spans far more than EC2 alone, including CloudFront, ECS, EKS, Elastic Load Balancing, EMR and OpenSearch Service, out of 34 components AWS tracks in total, which reflects how tightly coupled the US-EAST-1 control plane is rather than a broad multi-service failure. No user reports were filed during this window. AWS's history shows 12 incidents in the last 90 days with a median duration of 2 hours 14 minutes, so this one closed faster than typical.
Learning
UptimeRobot's own probes against DynamoDB, S3 and SQS across three regions stayed at 100% uptime through this window, and that is not a contradiction. This incident was scoped to new EC2 instance launches, specifically the RunInstances and CreateFleet API calls, while existing instances and the storage and queue services being probed kept working normally. A launch-path fault like this will not show up in checks that hit already-running endpoints, because the thing that broke is the provisioning workflow, not the data plane your product depends on minute to minute. If your own systems don't launch new EC2 capacity, you would have seen nothing at all, and if they do, you'd have seen it as failed launches rather than downtime on anything already deployed. This is the pattern to remember: a clean uptime reading from your own monitoring and a real, AWS-confirmed fault can both be true at once, because they are watching different layers. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
