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

Observability Isn’t About the Tool. It’s About the Truth

APM tools stop at your infrastructure’s edge. Internet Performance Monitoring reveals the real cause of API latency across networks you don’t control.

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 API latency crosses company boundaries, traditional APM tools lose visibility, and Internet Performance Monitoring becomes the only way to pinpoint the root cause.

  • Traditional APM, RUM, and logging tools only monitor what’s inside your own infrastructure, leaving a critical blind spot across the Internet path between your systems and your customers.

  • In a real-world case, synthetic API testing from multiple ISPs and cities pinpointed backend application dependencies as the root cause in just three hours and 15 test runs.

  • Backend latency was cut nearly in half once teams had the data to direct their optimization efforts to the right layer of the stack.

  • Explore LM Internet Performance Monitoring to gain full-path visibility from user to origin across every layer of the Internet Stack.


An enterprise client reports latency. Your dashboards say everything is fine. They blame you. You blame them. Nobody can prove it either way.

This is where most monitoring efforts hit a wall. The conversation gets stuck on dashboards and tools instead of the one thing that actually matters: getting to the root cause, fast.

Observability should give you the ability to pinpoint problems quickly when your reputation and revenue are on the line. But most tools only see what’s happening inside your own infrastructure. When the issue lives somewhere between your systems and your customer’s systems, you’re flying blind.

What happens when two companies see the same issue differently?

A leading financial services provider (let’s call them Company A) was under pressure. A key enterprise client, Company B, reported delays of 3 to 6 seconds when hitting APIs embedded in their customer-facing apps.

  • Company B: “Your APIs are slow. It’s impacting our customer experience.”
  • Company A (relying on Datadog APM): “Everything looks fine on our side.”

A stalemate, and a textbook case of observability failure.

Why couldn’t Datadog find the issue?

Datadog is an excellent Application Performance Monitoring (APM) tool, but it wasn’t built to see beyond your own infrastructure.

Even though Company A had robust APM and logging, they couldn’t see anything outside their own walls. They couldn’t install agents in Company B’s infrastructure, and they couldn’t drop Real User Monitoring (RUM) scripts into someone else’s codebase.

Here’s what each tool can (and can’t) do:

  • APM (like Datadog): Great inside the app, once traffic arrives.
  • RUM: Excellent for frontend insights, but only if you own the app.
  • Logs: Useful for what already happened, but not where packets got stuck in transit.

The common denominator: none of them can see what’s happening between systems. Here’s why.

Why do APIs create blind spots between companies?

APIs are the interface between companies. Just like you don’t walk into a restaurant kitchen to talk to the chef, companies don’t peek behind each other’s firewalls. They interact through APIs, exchanging structured requests and responses without seeing what’s happening on the other side.

That’s where blind spots show up.

When two systems communicate through APIs, neither has visibility into the other’s inner workings. The moment a request leaves your infrastructure, it enters the black box of “someone else’s problem,” including infrastructure, networks, and dependencies you don’t own and can’t instrument.

The core problem is that the Internet isn’t instrumentable. You can’t deploy agents or RUM scripts across networks and infrastructure you don’t control. That’s why traditional observability tools stop at the edge. Beyond that, you’re guessing.

But delivering a great digital experience depends on multiple networks, protocols, agents, and sub-systems working together. These dependencies form what’s known as the Internet Stack.

The Internet Stack

The Internet Stack is the collection of technologies, systems, and services that make possible and impact every digital user experience, from the core Internet systems like BGP, network technologies like TCP/IP, security technologies like SASE, protocols like QUIC or POP, cloud services, third party dependencies including APIs and web services, and SaaS applications. The term refers to all IP-based networks including the public Internet, private networks, and everything in between.

When performance breaks down somewhere in that chain, it doesn’t matter if it’s your fault or not. Your customers still feel it. APIs were designed for efficiency, not visibility.

This is where LM Internet Performance Monitoring (IPM) becomes essential. IPM gives you deep visibility into every layer of the Internet that can impact your service. Think of it as APM for the Internet Stack, purpose-built for the systems you don’t own but still rely on.

How do you get to the truth when APM falls short?

When traditional observability tools couldn’t explain the latency, Internet Performance Monitoring filled the gap. Instead of guessing, Company A used IPM to run synthetic API tests across real-world networks:

  • From user ISPs: major U.S. carriers and fiber providers
  • From backbone and enterprise vantage points
  • From inside Company A’s own infrastructure

Each test simulated actual API calls, complete with traceable request IDs and timestamps. The results were clear.

This diagram maps the full path of an API call, from the client through Akamai, to internal proxy infrastructure and upstream systems. It shows where latency accumulates:

  • DNS, connect, and SSL times are negligible.
  • Akamai’s edge processing is fast (~48ms).
  • Major delays occur during origin fetch (3,143ms) and proxy fetch (2,364ms), both inside the server infrastructure.
  • This confirms the problem isn’t with the client or CDN, but deep in the backend.

Latency breakdown across cities

This chart tracks average response and wait times across major U.S. cities. The key insight:

  • Latency patterns are remarkably consistent across geography.
  • A single spike appears across multiple regions, ruling out a location-specific issue.
  • This supports the conclusion that the bottleneck lives within the origin infrastructure, not in external networks.

ISP breakdown

Here, performance is analyzed by ISP (e.g., AT&T, Comcast, Verizon):

  • Despite some noise, the pattern is stable across providers, with no single ISP showing consistently worse performance.
  • This helps eliminate ISP-side routing or congestion as a root cause.
  • The brief AT&T spike aligns with the same moment seen in city-level data.

The result: Consistent 3 to 6 second latency, both internally and externally.

With that data, they could rule out the usual suspects:

  • It wasn’t the ISP.
  • It wasn’t the CDN.
  • It wasn’t DNS.
  • It wasn’t the proxy (Envoy).

The process of elimination worked like a proper diagnostic: isolate each layer, eliminate what’s clean, and close in on the source. Parsing response headers like x-envoy-upstream-service-time confirmed the latency was occurring further upstream, deep within Company A’s own service environment. This pointed engineers in the right direction without them needing to sift through endless log lines. Trace IDs and timestamps were shared with internal teams to help pinpoint issues around application dependencies, which were confirmed as the root cause.

This methodical approach, including initial discussion and setup, took just three hours and about 15 test runs. No guesswork, just clarity.

After internal validation, teams began work on the improvements, which are still ongoing but already measurable where it matters most.

Backend latency has dropped significantly: both upstream service time and overall wait time have been cut nearly in half. These gains reflect steady optimization efforts that are clearly moving in the right direction.

What IPM delivers that APM can’t

Datadog, New Relic, and Dynatrace are strong at what they do inside your infrastructure. But they weren’t designed to monitor the Internet itself.

Internet Performance Monitoring was built for exactly that. Here’s how:

A global agent network

  • 3,000+ agents across last-mile, backbone, cloud, enterprise, and on-prem environments
  • Real-user network emulation, not cloud-only testbeds

Full synthetic coverage

  • HTTP/S, APIs, Browser, DNS, SSL, BGP, MQTT, QUIC, Custom scripts

Advanced diagnostics

  • Packet loss, jitter, path tracing, hop analysis
  • Region-specific degradation detection

Frontend visibility

  • WebPageTest for in-depth frontend performance analysis
  • Browser + mobile RUM SDKs for teams who can instrument the frontend

Seamless integration

  • Feeds directly into Datadog, Splunk, New Relic, Dynatrace
  • Enhances existing observability stacks without replacing them
  • Provides end-to-end visibility across the Internet Stack via a real-time dependency map

And because Catchpoint is part of the LogicMonitor platform alongside LM Envision and Edwin AI, teams get a unified view from user to code. Internet performance data flows into the same telemetry pipeline and context graph that covers infrastructure, cloud, and applications, giving operations teams a single system to detect, understand, and act on issues across the full digital path.

Why teams cling to familiar tools even when they’re not fit for purpose

Familiar tools are comfortable. They’re deployed, widely understood, and politically safe. But comfort sometimes wins out over capability, especially in large, mature organizations where tooling decisions are influenced by inertia rather than fitness for purpose. When seconds matter and customers are impacted, you need clarity, not comfort.

Who takes the blame when APIs are slow?

In this case, Company B blamed Company A. Company A blamed Company B. Neither had data to prove their case.

Meanwhile, users just saw a slow experience.

End users don’t know an API call is crossing company boundaries. They only see the brand they’re interacting with. If it’s slow, they assume that brand is to blame. Solving performance issues quickly is about more than technical hygiene. It’s about protecting business relationships and customer trust.

The real job of observability

Observability should get you to the truth, fast. And often, the truth lives outside your four walls.

In an AI-driven world, data powers decisions. But if your data is incomplete or your telemetry is limited to your own infrastructure, your AI models are working with partial information.

LM Internet Performance Monitoring gives teams the ability to:

  • Validate performance from the outside in
  • Prove or disprove internal assumptions with independent data
  • Pinpoint root causes in minutes, not days

The point of observability is getting to the answer. LM Internet Performance Monitoring makes that possible across the full Internet path, not just inside your own environment.

See where your APIs lose time across the Internet Stack.

LM Internet Performance Monitoring gives your team full-path visibility from user to origin, so you can resolve latency issues in hours, not days. Pair it with LM Envision and Edwin AI for a unified view across your entire digital path.

FAQs

How does Internet Performance Monitoring differ from APM?

APM monitors application performance inside your own infrastructure. Internet Performance Monitoring extends visibility to the networks, ISPs, CDNs, and DNS layers between your systems and your users. Together, they provide full-path observability from code to customer.

Can LM Internet Performance Monitoring work alongside existing tools like Datadog or New Relic?

Yes. LM Internet Performance Monitoring integrates directly with Datadog, Splunk, New Relic, and Dynatrace. It enhances your existing observability stack by adding external network visibility without replacing any current tooling.

How quickly can Internet Performance Monitoring identify the root cause of cross-boundary latency?

In the case study described in this article, the team identified the root cause in approximately three hours using about 15 synthetic test runs. The structured diagnostic approach eliminates guesswork by systematically ruling out each layer of the Internet Stack.

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

Edwin AI and the New Requirements for Operational Resilience in ITOps
Blog AIOps & Automation

Edwin AI and the New Requirements for Operational Resilience in ITOps

Operational resilience depends on more than detecting incidents. Learn how Edwin AI helps ITOps teams connect signals, isolate root cause, predict risk, and respond faster across hybrid environments.
September 4, 2026
Learn more
How to Use Quarkus Live Coding (Live Reload) in Docker
Blog

How to Use Quarkus Live Coding (Live Reload) in Docker

Build a faster Quarkus development loop with Docker: enable remote Live Coding, reload code changes instantly, and troubleshoot containers before production.
September 2, 2026
Learn more
The $1 Million Lesson: Building a Culture of Quality Through SLAs
Blog Internet Performance Monitoring

The $1 Million Lesson: Building a Culture of Quality Through SLAs

A single $1M SLA penalty taught one lasting rule: measure service the way your customers feel it. Here’s how to build SLAs that hold up and protect revenue.
September 1, 2026
Learn more