Loading full navigation.

Autonomous IT is here. The alert loop ends now. LEARN MORE

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

LOGICMONITOR BLOG

How ServiceNow Contained a Major ISP Outage with Internet Performance Monitoring

Learn how ServiceNow used Internet Performance Monitoring to trace a Zayo ISP failure, reroute BGP traffic, and contain a two-hour disruption before it reached its users.

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 an upstream ISP fails, the teams that see the full internet path recover faster than the teams that only watch their own infrastructure.

  • This deep dive into a ServiceNow ISP outage shows how independent Internet Performance Monitoring turns a black-box upstream failure into a controllable incident, giving ITOps teams the visibility they need to act before users feel the impact.

  • Internet Performance Monitoring alerts, synthetic tests, traceroute data, and BGP events mapped the affected paths and the blast radius.

  • BGP events climbed from 178 the prior day to 491 during the outage as ServiceNow deprioritized the Zayo link and restored connectivity through alternate providers.

  • Map the full path between your users and your services now, and test your BGP failover before an ISP forces the test for you.

Every enterprise depends on SaaS platforms that route through upstream Internet paths outside their direct control. When one of those paths fails, internal monitoring sees nothing until users start complaining. On August 15, 2024, that’s exactly what happened to ServiceNow: a 2-hour, 3-minute disruption caused by instability at upstream ISP Zayo (AS 6461) affected portal resources and client integrations across thousands of organizations. The incident made one thing clear: enterprises need independent visibility into the Internet infrastructure their services depend on, not only the systems they own.

Internet Performance Monitoring data revealed exactly how the incident unfolded: synthetic monitoring, traceroute data, and BGP routing events all contributed to identifying the affected paths and understanding the blast radius. The data shows that ServiceNow took proactive steps to reroute traffic, deprioritize the unstable upstream link, and restore connectivity before the incident could escalate further.

This article discusses what happened, how it was detected, and what the BGP data reveals about ServiceNow’s response.

Why this outage matters now

Modern digital operations depend on far more than the infrastructure an organization owns. Employees, customers, and partners access critical SaaS platforms from distributed locations, home networks, office networks, mobile networks, ISPs, cloud regions, and third-party delivery paths. As hybrid work and SaaS dependency sprawl grow, availability is no longer determined only by whether an application or server is healthy. It also depends on whether users can reliably reach that service across the Internet.

That distinction matters during incidents like this one. ServiceNow took steps to reroute traffic and restore reachability, but customers still needed outside-in visibility to understand what was happening from their own vantage point. Was the issue with ServiceNow itself, an upstream ISP path, their own network, or a broader Internet disruption? Without independent Internet Performance Monitoring, teams can lose valuable time trying to answer that question.

Traditional infrastructure monitoring tells teams whether the systems they own are healthy. Internet Performance Monitoring shows whether users can actually reach the services they depend on across DNS, ISP paths, BGP routes, cloud networks, and third-party delivery infrastructure. Internal dashboards may show applications, servers, or cloud resources as healthy while users are still experiencing timeouts, slow connections, or failed access because the problem exists somewhere along the Internet delivery path.

In this incident, that outside-in view helped reveal intermittent reachability, high connection times, traceroute changes, and BGP instability tied to the upstream provider path. The data that follows breaks down exactly how that played out.

How the ServiceNow outage unfolded

On August 15, 2024 at 14:15 ET, ServiceNow’s core services went down. Reports indicated intermittent success based on connectivity with upstream providers. Failures continued until 16:18 ET, spanning a window of 2 hours and 3 minutes. The outage affected ServiceNow’s portal resources as well as client integrations.

Scatterplot highlights intermittent failures due to Network Outage

Internet Performance Monitoring tools from Catchpoint, a LogicMonitor company, began triggering alerts by correlating thresholds against existing synthetic test configurations. Internet Sonar dynamically populated outage data with Response and Connection Timeout errors from major geographic locations. Observing the outage trend, we found resources to be intermittently reachable while the majority of requests faced high connect times.

Internet Sonar Dashboard of ServiceNow incident

Waterfall data highlighting High Connection Time and Internet Sonar correlation with ServiceNow’s regional outage

This outage resulted from instability in ServiceNow’s connectivity with its upstream providers, particularly AS 6461 (Zayo).

This behavior was observed using Catchpoint’s Traceroute monitor.

15th Aug 11:00 EST to 14:00 EST, before the outage

15th Aug 14:15 EST to 16:20 EST, during the outage

15th Aug 16:20 EST to 18:00 EST, after the outage

ServiceNow uses multiple ISPs for its datacenter locations, as listed in this support article. The core ISPs with a direct neighbor relationship to ServiceNow include Lumen (3356), Cogent (174), Zayo (6461), Level3 (3356), AT&T (7018), and Verizon (6167).

Before the outage, AS 6461 (Zayo) was one of the most favorable paths for incoming traffic to ServiceNow:

RIPEstat: IPV4/6 ASN Neighbours of ServiceNow

When Zayo began experiencing major issues, the instability caused path fluctuations. That led the ServiceNow team to work through multiple BGP events (announcements, re-announcements, and withdrawals) to reroute traffic.

RIPEstat BGP activity: Spike in announcements and withdrawals

Let’s break down the BGP activity from RIPEstat across three phases:

  • Before the outage
  • During the outage
  • After the outage

Before the outage (August 14, 00:00 to 23:59 UTC), a total of 178 events were observed for AS 16839. These events reflect BGP activity within the ServiceNow ASN, including neighboring changes:

During the outage on August 15, compared to the day before, the number of events increased sharply to 491, with significant route withdrawals and re-announcements.

This abnormality highlights the network volatility as the ServiceNow team worked (manually or via automation) to keep their services reachable from the Internet. While those changes were being made, the ServiceNow portal and partner integrations continued to have connectivity issues.

After the outage, it was observed that the ServiceNow ASN was no longer connected to or receiving traffic directly through Zayo. This points to the issue being specific to the Zayo-ServiceNow link during the incident. BGP did its job: traffic found a reliable path to ServiceNow via its other providers.

The Zayo-ServiceNow link issue was resolved about 10 hours after the first signs of the incident (August 15, 20:25 UTC to August 16, 06:28 UTC), and traffic began routing through the originally preferred links again:

Viewing the network outage

In addition to synthetic test alerts, the following sequence was observed:

  1. Initial re-announcements and prepending
  2. Path fluctuations and community tags
  3. Route withdrawals and re-announcements
  4. Path changes involving prepending and path optimization
  5. Final stabilization

At 15:51 EST, the data showed services beginning to return to normal as the ServiceNow team rolled back routes and redirected traffic to alternate IPs based on the BGP events.

As the snippet above shows, traffic was routed differently before, during, and after the incident. Requests were redirected in real time to a new IP, 149.95.29.217, instead of the original IP 149.95.45.217 (part of subnet 149.95.16.0/20). This was part of the mitigation process, deprioritizing traffic via Zayo using BGP updates.

Building resilience for future Internet outages

Even though organizations have limited control over Internet-layer infrastructure, this outage offers several practical takeaways. When BGP events occur, the speed and quality of response directly determines whether an incident stays contained or escalates into a prolonged outage. The ServiceNow team acted on the network fluctuations they observed: they rerouted traffic, adjusted BGP configurations, and restored connectivity to core resources and client integrations.

This incident reinforces several operational practices that organizations should evaluate:

  • Monitor the full path between users and content. Infrastructure inside the firewall is only part of the picture. ISP links, peering arrangements, and upstream provider health all affect availability. Internet Performance Monitoring (IPM) gives teams visibility across every layer of the application delivery chain, from DNS and CDN to cloud infrastructure and datacenter connectivity.
  • Define and test fallback mechanisms. Multi-provider redundancy only works if failover paths are validated before an incident. Regularly test BGP failover scenarios and document expected behavior for each upstream provider.
  • Hold vendors accountable with data. When an upstream provider contributes to an outage, you need independent telemetry to substantiate impact. Without it, SLA enforcement becomes guesswork.
  • Strengthen Incident Management practices. Review your own incident response workflows and those of your vendors. The time between detection and action is where outcomes are decided. Reducing mean time to detect (MTTD) through proactive, end-to-end monitoring shortens the overall incident lifecycle.
  • Validate mitigation plans under realistic conditions. A documented plan that hasn’t been tested is a liability. Run tabletop exercises and simulated failovers to confirm that routing changes, IP redirects, and provider cutover procedures work as expected.

Application delivery depends on a chain of interconnected components: DNS, load balancers, CDNs, cloud infrastructure, datacenters, and the network layer that connects them. Incidents like this demonstrate how a single upstream provider issue can cascade across an organization’s services and end-user experience.

A unified monitoring approach, one that connects infrastructure observability, Internet performance, and digital experience in a single platform, gives teams the context they need to detect these issues early, understand the blast radius, and respond before the business impact grows. LogicMonitor, which brings together LM Envision, Internet Performance Monitoring, and Edwin AI, is designed to maintain SLAs and close the gap between detection and resolution across every layer of the stack.

See the internet paths your infrastructure monitoring can’t reach.

LogicMonitor unifies infrastructure, synthetics, and Internet Performance Monitoring in one platform, so you can watch your systems and the DNS, ISP, BGP, and cloud paths that connect users to them. Act before an upstream provider decides your recovery time for you.

FAQs

What is Internet Performance Monitoring (IPM), and how does it differ from traditional infrastructure monitoring?

Traditional infrastructure monitoring tells you whether the systems you own are healthy. IPM tells you whether users can actually reach your services across DNS, ISP paths, BGP routes, cloud networks, and third-party delivery paths. During the ServiceNow event, that outside-the-firewall visibility identified an upstream ISP as the source, which internal metrics alone would have missed.

How did IPM help ServiceNow diagnose the August 2024 outage?

Catchpoint, part of LogicMonitor combined Internet Sonar alerts, synthetic monitoring, traceroute data, and BGP routing events to isolate the failure at upstream provider Zayo (AS 6461). That telemetry showed which paths were affected and how wide the blast radius was. It also tracked BGP events rising from 178 the day before to 491 during the outage as traffic rerouted.

What can IT teams do to prepare for an upstream ISP failure?

Monitor the full path between your users and your content, then define and test BGP failover so alternate routes work under pressure. Hold providers accountable with independent telemetry, and strengthen incident management to reduce mean time to detect. Validating your mitigation plan in advance shortens recovery when an ISP becomes unstable.

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

AI Agents Are Becoming Part of the IT Environment. They Need to Be Managed That Way.
Blog AIOps & Automation

AI Agents Are Becoming Part of the IT Environment. They Need to Be Managed That Way.

Agent Studio for Edwin AI gives administrators one place to see which agents are available, understand what each one does, control which agents are enabled, and manage their access to MCP tools. See how Agent Studio brings clearer administration and governance to agentic IT operations.
October 14, 2026
Learn more
From Systems of Intelligence to Systems of Action: Innovations Across the Autonomous IT Platform
Blog Observability

From Systems of Intelligence to Systems of Action: Innovations Across the Autonomous IT Platform

IT operations are moving from systems that explain to systems that act. Here’s every innovation LogicMonitor announced at Elevate 2026, and where to start.
October 14, 2026
Learn more
The Foundation Under Autonomous IT: Why AI-Ready Data Comes First
Blog Observability

The Foundation Under Autonomous IT: Why AI-Ready Data Comes First

AI for IT operations is only as trustworthy as the telemetry beneath it. Learn what makes telemetry AI-ready and how to build a stronger foundation for Autonomous IT.
October 14, 2026
Learn more