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: The AWS Outages That Proved the Value of Independent Monitoring

Internet Performance Monitoring detected the AWS outages before AWS acknowledged them. Learn why independent, outside-in monitoring is critical to faster incident response.

5–8 minutes
Denton Chikura

NEWSLETTER

Subscribe to our newsletter

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

SHARE

The quick download:

Outside-in monitoring detected all three AWS outages before AWS confirmed them, giving teams advance warning of customer-facing impact.

  • One incident was detected about two hours before AWS acknowledged it, giving teams critical response time.

  • Cloud dependencies cascade: a single regional failure in US-EAST-1 disrupted services far beyond that region because of shared control functions.

  • When your monitored environment fails, your monitoring should stay online. Several major observability vendors reported their own impacts during these outages.

  • Combine internal infrastructure monitoring with outside-in Internet visibility to detect customer impact before provider status pages catch up.

Businesses depend on cloud infrastructure for customer-facing websites, mobile apps, internal business systems, APIs, identity services, and transaction processing. When a major cloud provider experiences an outage, the impact can spread across streaming platforms, smart-home services, delivery applications, workplace tools, and other services that rely on shared infrastructure.

The provider may not confirm the problem immediately. Customers can encounter errors or degraded performance while internal teams are still investigating the cause.

This happened three times in December 2021. The incidents had different technical causes, but each showed how quickly a failure in shared cloud infrastructure can affect dependent services.

The three incidents were:

  • December 7, 2021: A failure involving several network devices in US-EAST-1 degraded EC2, connectivity, and dependent services for several hours.
  • December 15, 2021: Network congestion affected AWS regions in Oregon and Northern California, slowing traffic across the West Coast.
  • December 22, 2021: A data center power loss took EC2 instances offline in one US-EAST-1 availability zone.

For organizations that depend on cloud providers, these incidents offer practical guidance on detection, dependency planning, monitoring independence, and Internet resilience.

Early detection gives teams more time to respond

Catchpoint, a LogicMonitor company, observed all three incidents before AWS posted an acknowledgment on its status page.

On December 7, connectivity issues were detected affecting AWS servers at 10:33 a.m. ET. AWS posted its first acknowledgment at approximately 12:37 p.m. ET, giving engineers close to two hours of advance notice.

Waterfall graph indicating a 504 error response for the Amazon site

On December 15, degradation in US-West-2 and US-West-1 was detected at approximately 10:15 a.m. ET. AWS posted an update around 10:43 a.m. ET.

User sentiment analysis

On December 22, the incident was detected at 7:11 a.m. ET, approximately 24 minutes before AWS published its notice.

Proactive Chrome browser observer showing the AWS outage.

The time difference matters during a production incident. Early detection gives engineers more time to confirm the scope of the problem, review failover options, communicate with customers, and decide whether the issue requires a provider escalation.

A provider status page reports what the provider has confirmed internally. That process can take time while engineers investigate, verify the impact, and prepare an update. External monitoring measures the customer experience as it changes.

Cloud dependencies can turn one regional failure into a wider outage

Cloud architecture reduces the amount of infrastructure teams need to operate themselves, but it does not remove dependency risk. A service may rely on several AWS regions, managed DNS, content delivery networks, identity providers, Internet service providers, and external APIs.

The December 7 incident demonstrated how a failure in US-EAST-1 could affect a broad range of services. US-EAST-1 also carries shared AWS control functions and dependencies that can affect workloads believed to be distributed across regions.

A design may appear geographically distributed while still relying on a common control plane, DNS provider, identity service, or network path. If teams do not know about those shared dependencies, their failover plans may not work as expected.

Third-party dependency mapping helps teams document the external services and providers involved in delivering a digital experience. That view can reveal dependencies involving DNS, CDNs, cloud services, and other providers.

Dependency mapping is useful before and during an incident. Before an outage, it supports decisions about multi-region, multi-cloud, and provider fallback strategies. During an outage, it gives engineers a current view of the request path, making it easier to determine which services are likely to be involved.

A dependency inventory should answer questions such as:

  • Which providers handle DNS for the service?
  • Which CDN serves the customer-facing content?
  • Which identity or payment services must respond before the user journey can continue?
  • Which services share a cloud region or network provider?
  • What happens if one of those dependencies becomes unavailable?

The answer to each question can affect the incident response plan.

Monitoring should remain available when the monitored environment fails

A monitoring system hosted in the same environment as the services it observes may experience the same outage.

During the December incidents, several monitoring providers reported service impacts. Datadog experienced delays affecting AWS integration metrics. Splunk SignalFx reported issues with AWS metric ingestion and other services. New Relic reported delays involving infrastructure metrics, synthetics, and alerting. Other monitoring vendors also reported degradation.

When the monitoring system is affected, engineers may lose access to the evidence they need to understand the incident. Alerting and paging can also fail if those systems depend on the same cloud region or network path.

Adrian Cockcroft described the need for monitoring systems whose failure modes are independent of the infrastructure they monitor:

“The first thing that would be useful is to have a monitoring system that has failure modes which are uncorrelated with the infrastructure it is monitoring.”

Independent, outside-in monitoring provides a separate source of evidence. It can continue reporting when an affected region, cloud account, or internal monitoring service is unavailable.

The same principle applies to incident communication. Teams should review whether alert delivery, paging, status communication, and escalation workflows depend on the infrastructure under investigation.

What the December outages still teach IT teams

The AWS outages from December 2021 remain useful because they show how failures spread through connected digital services.

The main lessons are straightforward:

  1. Detect customer impact before provider confirmation. External tests can show when users begin experiencing errors or latency.
  2. Map dependencies before an incident. Teams need to know which cloud regions, DNS providers, CDNs, ISPs, and APIs support each service.
  3. Keep monitoring independent. A separate monitoring path should continue reporting when the monitored environment is unavailable.
  4. Combine internal and outside-in evidence. Infrastructure health alone does not explain every customer-facing failure.
  5. Test the response plan. Teams should know how they will fail over, contact providers, route traffic, and communicate during a regional or provider outage.

Cloud providers operate highly engineered infrastructures, but no shared platform is immune to failure. Resilience depends on how well an organization understands its dependencies, how early it detects customer impact, and whether engineers have enough independent evidence to make sound decisions during the incident.

For teams operating across cloud, network, and Internet dependencies, the practical goal is clear: maintain visibility across the systems you control and the paths your customers use to reach them.

Pairing internal and Internet visibility prepares teams for the next outage

The December 2021 AWS outages point to a durable practice: monitor both the systems you control and the Internet paths customers use to reach them. LogicMonitor Envision covers cloud, network, and application infrastructure, while LogicMonitor Synthetics and Internet Performance Monitoring provide outside-in visibility beyond the firewall.

Neither view tells the whole story. Internal telemetry may show healthy systems while customers encounter failures caused by a CDN, DNS provider, ISP, or routing issue. Outside-in tests can confirm customer impact without identifying the internal component responsible.

Together, these platforms narrow the investigation from the start of an incident. Engineers can determine whether to involve the network team, investigate an application, or open a provider ticket.

That combined view supports earlier detection and more accurate response, providing a foundation for Autonomous IT. When the next cloud outage occurs, teams with visibility across infrastructure and Internet paths will have the evidence they need to respond with greater confidence.

See how LogicMonitor detects outages before your provider does.

Pairing internal infrastructure monitoring with outside-in Internet visibility gives your team the early warning and independent evidence needed to act fast. See it in action.

FAQs

How did Internet Performance Monitoring detect the AWS outages before AWS acknowledged them?

Internet Performance Monitoring measures customer experience from outside the cloud environment. This outside-in approach detected degraded performance during all three December 2021 incidents (by roughly two hours, 28 minutes, and 24 minutes respectively) before AWS status pages confirmed the issues. Provider status pages report only confirmed internal information, while external monitoring captures the customer impact as it happens.

Why did a failure in US-EAST-1 affect services across other regions?

US-EAST-1 carries shared control functions that other AWS regions and services depend on. When that region experienced issues, the failure cascaded through those dependencies to affect services that appeared to be in separate locations. This is why third-party dependency mapping of DNS, CDNs, identity providers, and payment systems is critical for understanding real exposure.

Why should monitoring remain independent from the infrastructure it observes?

During the December 2021 outages, several major observability vendors including Datadog, Splunk SignalFx, and New Relic reported their own service impacts. When your monitoring runs on the same infrastructure you’re watching, it can fail at exactly the moment you need it most. Independent outside-in monitoring provides separate evidence and stays available when your primary environment goes down.

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

Outage Retrospective: The AWS Outages That Proved the Value of Independent Monitoring
Blog Internet Performance Monitoring

Outage Retrospective: The AWS Outages That Proved the Value of Independent Monitoring

Internet Performance Monitoring detected the AWS outages before AWS acknowledged them. Learn why independent, outside-in monitoring is critical to faster incident response.
September 14, 2026
Learn more
Why Government IT Needs AI-Powered Observability
Blog Observability

Why Government IT Needs AI-Powered Observability

Legacy systems, cloud growth, and AI are reshaping government IT. See how connected visibility helps teams respond faster and keep essential services running.
September 14, 2026
Learn more
Observability ROI: Real Savings From Real Deployments
Blog

Observability ROI: Real Savings From Real Deployments

Observability can cut alert noise, speed up incident response, reduce downtime, and give engineers more time for planned work. LogicMonitor customers have used those gains to lower costs and make better infrastructure decisions.
September 9, 2026
Learn more