The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.
Try it free

14-day access to the full LogicMonitor platform

The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

LOGICMONITOR BLOG

Outage Retrospective: How a Localized AWS Disruption Escaped Status Pages

An AWS micro-outage slipped past status pages while users felt the disruption. See how outside-in Internet visibility catches what internal tools cannot.

6–9 minutes
Denton Chikura

NEWSLETTER

Subscribe to our newsletter

Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

SHARE

The quick download

When your provider says green and your users say broken, believe your users.

  • A 25-minute AWS micro-outage disrupted S3, EC2, CloudFront, and Lambda for traffic crossing Lumen and CenturyLink networks, while AWS’s status page was clear.

  • Internal telemetry and provider dashboards cannot see failures in the ISPs, transit paths, and peering points that are between your users and your services.

  • Just 25 minutes of downtime can cost a 0.06% SLA hit, plus reputation damage your users pin on you rather than the cloud provider.

  • Pair outside-in Internet visibility with infrastructure observability so you can detect disruptions from the user’s perspective and respond with evidence.

Your users can be affected even when your cloud provider, status page, and internal monitoring say everything is fine. That disconnect is the real risk of what we call micro-outages: incidents too small or too localized to trigger a provider acknowledgment, yet disruptive enough to degrade real user experience, breach SLAs, and erode trust.

While major outages like the CrowdStrike incident dominate headlines, most disruptions look different. They’re localized by geography, autonomous system, or transit path. They don’t make the news. They don’t appear on status pages. But they still cost money, damage reputation, and leave teams scrambling without answers.

Every enterprise depends on layers outside its direct control: cloud providers, ISPs, DNS, CDNs, peering points, and routing infrastructure. When any of those layers fails, your users feel it, even if your internal telemetry shows green across the board. The challenge is seeing what’s happening outside your environment before your users start complaining.

An AWS micro-outage illustrates this problem clearly. Catchpoint, a LogicMonitor company, detected the disruption while AWS’s own status page showed no issues during the entire event.

What happened during the AWS micro-outage

On August 14 2025, between 8:00 and 8:25 UTC, Internet Sonar, detected connection timeouts impacting multiple AWS services (S3, EC2, CloudFront, and Lambda) across several regions. The timeouts were observed from locations on CenturyLink AS209 and Lumen (Level 3) AS3356.

The event didn’t cause a complete outage, but it had a measurable impact on the ability of traffic from these networks to reach AWS services.

Dashboard showing the impact of AWS’s micro-outage, with connection issues detected across different AWS regions, for multiple services.

Waterfall record showing test failures due to connection times, along with Internet Sonar root cause indicating AWS incidents

%Downtime across different services in multiple regions

Further investigation revealed that the connection timeouts primarily occurred when traffic originated from or passed through Level 3 AS3356 and CenturyLink AS209. This pattern pointed to potential peering issues between these transit providers and AWS.

The root cause of the peering issue remains unclear. However, only AWS was impacted from these two Lumen ASes.

Why micro-outages are hard to catch from the inside

This incident exposed a gap that affects every organization running on cloud infrastructure. Your internal telemetry can show your application is healthy while the external paths to that application are failing.

If you’re monitoring your app from inside the same cloud environment it runs on, a peering issue between a transit provider and your cloud platform won’t show up. Your servers respond. Your health checks pass. But a segment of your users can’t reach you. Internal tools don’t see what’s broken because the break is outside your environment, somewhere in the chain of ISPs, transit providers, and peering points that connect your users to your services.

This is the core argument for outside-in Internet visibility paired with internal observability. You need both perspectives to diagnose accurately: what your infrastructure sees, and what your users actually experience.

Status pages won’t tell you what your users are experiencing

During this incident, AWS’s official status page showed no issues. For the teams whose users were affected, that created a painful disconnect: “Our customers are complaining, but the provider says everything is green.”

Screenshot: AWS’s status page during the micro-outage

This isn’t unusual, and it isn’t because providers are hiding problems. Every cloud provider has its own thresholds and processes for determining whether an issue warrants a status page update. In many cases, providers may not be aware of a localized issue until customers report it. Some issues fall below the threshold for acknowledgment entirely.

Performance degradations and slowdowns are even less likely to surface on status pages, yet they can significantly affect user experience. Given the high cost of Internet disruptions, waiting for your provider to tell you something is wrong adds delay you can’t afford.

The takeaway is straightforward: teams need independent verification of service health. If your only signal is a provider status page, you’re operating with incomplete information during the moments that matter most.

A practitioner framework for third-party dependency incidents

This incident reinforces a pattern that applies to any third-party dependency, not just AWS. Whether the issue sits with a cloud provider, an ISP, a DNS provider, a CDN, or a peering point, the same framework applies.

Detect from outside in

Monitor your services from the perspective of your users, across different geographies, ISPs, and transit paths. Internal health checks can’t surface issues that originate outside your environment. Outside-in monitoring catches what internal tools miss.

Validate provider status independently

Don’t rely on provider status pages as your source of truth. Correlate what users report with what your own monitoring shows, independent of what the provider’s dashboard displays.

Isolate the path and provider impact

Determine whether the issue affects all users or a specific subset based on geography, ISP, or transit path. In this AWS incident, the impact was concentrated on traffic traversing two specific autonomous systems. That kind of isolation helps you understand scope and prioritize response.

Communicate with evidence

When users report problems and your provider says nothing is wrong, you need independent data to explain what’s happening. Evidence-based communication helps maintain trust with customers, even during disruptions you didn’t cause.

Test your fallback and contingency plans

Not every organization can afford multi-cloud or hybrid failover for every service. If a fallback isn’t feasible, the next best action is proactive, transparent communication with your users. Preparing for these scenarios before they happen (knowing who communicates, what evidence to share, and what workarounds exist) reduces the scramble when an incident occurs.

Don’t monitor your cloud provider from your cloud provider

This incident also highlights an architectural risk worth examining. If your monitoring infrastructure runs on the same cloud platform it’s supposed to monitor, you’ve introduced a single point of failure.

When that cloud provider has an issue, your monitoring goes down with it, or worse, it reports false negatives because it’s also affected by the same disruption. You end up with a blind spot precisely when visibility matters most.

This applies to synthetic monitoring as well. If your synthetic tests run from nodes hosted on the same cloud infrastructure, an outage affecting that provider can prevent your tests from detecting the problem. You’re measuring the health of a platform from inside that platform.

Diversifying where your monitoring runs, and ensuring you have independent vantage points outside your primary cloud provider, is a resilience architecture decision, not just a tooling choice.

Connecting outside-in visibility with infrastructure observability

Micro-outages like this one sit in the gap between what internal tools can see and what users actually experience. Closing that gap requires two complementary perspectives.

LogicMonitor provides outside-in Internet visibility: the ability to detect issues from the user’s perspective across ISPs, transit providers, peering points, CDNs, DNS, and cloud edges. The platform also delivers infrastructure observability and operational intelligence across hybrid environments, cloud services, applications, and logs. Together, they help teams connect user-facing symptoms to backend health and external dependency issues, reducing the blind spots between user experience, network paths, cloud services, and backend systems.

This combination of outside-in and inside-out visibility is what gives teams the independent evidence they need. When a provider says nothing is wrong, when internal dashboards show green, and when users are still complaining, the ability to see the full path from user to infrastructure turns confusion into clarity.

The cost of invisible incidents

Your users won’t blame the cloud provider. They’ll blame you.

If your clients are businesses and you have SLAs in place, an incident like this could lead to a breach. Just 25 minutes of downtime could result in a 0.06% hit to your SLA. If the provider hasn’t acknowledged the issue, your users are left with a poor experience and no explanation. Even when an explanation comes later, the damage to your reputation (and potentially your revenue) is done.

The goal is to detect issues earlier, reduce impact, and respond with evidence before problems spread. Teams that can independently verify what’s happening across their full digital path, from user to infrastructure, operate with greater confidence and protect both customer experience and business outcomes.

See disruptions before your users do.

LogicMonitor provides independent evidence the moment a provider goes quiet. Get ahead of the next micro-outage instead of explaining it after the fact.

FAQs

What is a micro-outage?

Answer 1: A micro-outage is an incident too small or too localized to trigger a provider acknowledgment, yet disruptive enough to degrade real user experience, breach SLAs, and erode trust. These events are often isolated by geography, autonomous system, or transit path, so they rarely appear on status pages even though users feel them.

Why didn’t AWS’s status page show the August 14 2025 issue?

Every cloud provider sets its own thresholds for status updates, and localized or below-threshold issues often go unacknowledged until customers report them. During this event, connection timeouts affected traffic crossing Lumen (Level 3) AS3356 and CenturyLink AS209, a peering-level problem that AWS’s dashboard never flagged.

How can teams catch micro-outages that internal tools miss?

Monitor services from the user’s perspective across different geographies, ISPs, and transit paths, and validate provider status independently. Pairing outside-in tools like Internet Sonar with infrastructure observability lets teams pinpoint which layer failed and communicate with evidence.

By Denton Chikura

Technical Writer

Denton Chikura is a technical writer and longtime observability advocate focused on helping site reliability engineers and engineering teams discover the tools and capabilities that strengthen internet resilience. He works at the intersection of monitoring, performance, and infrastructure to make complex systems more understandable and usable, bridging the gap between deep technical detail and real‑world operations. His goal is to help teams build faster, detect issues earlier, and recover smarter, ultimately making the internet a better, more reliable place for everyone.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

By Denton Chikura

Technical Writer

Denton Chikura is a technical writer and longtime observability advocate focused on helping site reliability engineers and engineering teams discover the tools and capabilities that strengthen internet resilience. He works at the intersection of monitoring, performance, and infrastructure to make complex systems more understandable and usable, bridging the gap between deep technical detail and real‑world operations. His goal is to help teams build faster, detect issues earlier, and recover smarter, ultimately making the internet a better, more reliable place for everyone.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

© LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Related Blogs

Is HTTPS the Answer to Man in the Middle Attacks?
Blog

Is HTTPS the Answer to Man in the Middle Attacks?

See how synthetic monitoring exposed a hidden HTTP redirect attack, and why HTTPS, HSTS, and delivery-path visibility keep your users safe from interception.
September 9, 2026
Learn more
Stale DNS Glue Records: How to Diagnose Parent-Authoritative Mismatches
Blog

Stale DNS Glue Records: How to Diagnose Parent-Authoritative Mismatches

Your authoritative servers return the right IP, but users still hit the old one. Here’s how to find stale glue records and fix the parent-zone referral.
September 9, 2026
Learn more
Leading Analyst Firm Reveals the Real Cost of Internet Disruptions
Blog

Leading Analyst Firm Reveals the Real Cost of Internet Disruptions

E-commerce companies lose $6M+ yearly to Internet disruptions. A Forrester study reveals how Internet Performance Monitoring cuts losses by over half.
September 9, 2026
Learn more