Jamie Beckland is Chief Product Officer at APIContext.
If you’ve been part of a major incident call, you’ve probably been part of the ‘not it!’ problem in modern IT:
“It’s not us.”
“It’s not the app.”
“It’s not the network.”
It’s not a lack of accountability, it’s a lack of shared visibility. In complex IT environments, performance issues can span multiple systems, vendors, and geographies. Each team may only have partial observability into their piece of the puzzle, making it impossible to see the full chain of events.
The result is the age-old “blame game” between IT, DevOps, application development, and networking teams. Without a unified view, everyone can honestly claim they’re “not it,” even while customers are experiencing slow or unavailable services. That means longer time-to-resolution (TTR) and declining operational confidence across the organization.
In the worst situations, edge cases can linger for months, not because the root cause is unfixable, but because there’s no clear path to resolution or even a plan to investigate. This prolonged uncertainty undermines trust between teams and erodes leadership’s confidence in operational readiness.
Inside vs Outside Observability
The root cause often lies in a split between two distinct perspectives:
- Inside observability: Internal signals from your own systems, such as CDN edge performance, WAF events, and origin response times. These metrics reveal how your infrastructure is behaving from the inside, showing server health, caching effectiveness, and firewall or security event activity.
- Outside observability: External measurements of the customer’s experience, such as DNS resolution, routing paths, and latency from different geographies. This data reflects what end users actually encounter when interacting with your applications, capturing the entire journey from their device to your infrastructure.
These two data sets rarely live in the same place. Inside data may be stored in a CDN’s native analytics tool or a log visualization platform. Outside data might sit in a network monitoring service, a synthetic testing platform, or be gathered from real user measurements. Without correlation, it’s difficult to determine whether an issue begins at the network edge, in the application, or somewhere in between.
The absence of a single, combined view means that even the most capable teams can waste valuable time debating which side of the wall the problem belongs on. Meanwhile, the customer experience continues to degrade.
The Solution: Merging Synthetic Data with CDN/WAF Visibility
When you combine synthetic monitoring data with your CDN and WAF log visualization platform, you close the gap between what your customers experience and what your infrastructure reports. Synthetic monitoring provides an “outside-in” view, running continuous tests from multiple geographies and networks to simulate real user journeys. These tests capture every step of the experience from DNS resolution and routing to TLS handshake and application response, across the internet’s many handoffs.
On the other side, your CDN and WAF logs offer a deep “inside-out” perspective: how requests arrive at the edge, how they’re processed, how caching and security policies behave, and how origin servers respond under different conditions.
Bringing these two streams of telemetry into the same visualization environment creates a single, end-to-end map of the journey: from the customer’s first request, to the edge, through to the origin, back to the edge, and ultimately back to the customer. By correlating timestamps and events automatically, you eliminate the need to switch tools or manually align datasets. The result is immediate clarity on whether performance issues originate in the public internet, at the edge, within the application, or in the path back to the user, giving your teams a complete picture to work from.
Move From Finger Pointing to Faster Fixes
Combining inside and outside observability provides many benefits, including:
- End the finger-pointing: When all teams work from the same correlated data set, the “not it” stalemate ends. Engineers no longer have to defend their domain without full context, and incident calls shift from arguing about where the problem is to discussing how to fix it. This cultural change improves collaboration and builds trust between functions.
- Accelerate time-to-resolution: Integrating inside and outside observability makes it possible to pinpoint the problem source almost immediately. For example, if a slowdown appears only in synthetic results from a certain geography, but edge logs show no congestion, you can narrow the scope to an external DNS or routing issue in minutes instead of hours. Faster isolation means customer impact is minimized and SLAs are easier to meet.
- Improve operational confidence: With a unified view, you can confidently manage multi-CDN and hybrid-cloud environments without guesswork. Instead of hoping that internal metrics are telling the full story, you can verify them against independent, outside-in measurements. This assurance lets you make informed capacity and architecture decisions that stand up to real-world conditions.
- Ensure cost-effective scale: Robust synthetic monitoring adapts to demand without forcing you to store massive amounts of additional logs. Log visualization should be optimized for high-volume, cost-efficient log ingestion, and combining these capabilities allows you to expand visibility without introducing unsustainable storage or processing costs.
Together, these benefits translate into faster resolution, reduced downtime risk, and a more predictable operations environment.
Where This Visibility Matters
Combining these two signals creates new insights in a wide variety of situations:
- Regional slowdown affecting customer transactions: Customers complain of slow checkout, but application metrics are all “green.” There’s no clear source of slowness inside the network. External call data, however, reveals elevated DNS resolution times in isolated geographies that representing 30% of customer volume. The networking team works with the DNS provider to resolve the issue, restoring performance quickly and avoiding unnecessary escalations across other teams.
- Application performance degradation traced to routing changes: Transaction volume drops with no clear attributable reason. Initial investigations show that the network is operating normally from the inside. Multi-cloud synthetics, however, reveal latency spikes along a specific ISP route. With this evidence, the operations team escalates to the ISP and gets routing adjusted, preventing prolonged customer impact.
- Branch location suffers timeouts: Employees at certain branch locations report periodic application timeouts, making it impossible to serve customers efficiently. Internal networking telemetry shows no cause for the failures. Synthetic telemetry highlights that the affected branches share a common upstream bottleneck. Once identified, the networking team upgrades the infrastructure, resolving the issue for all impacted branches.
In each case, having an integrated view prevents wasted cycles on the wrong hypothesis and allows teams to focus their efforts on the real cause.
KPIs You Can Track from Day One
From the moment you connect synthetic monitoring to log storage, you can monitor:
- DNS resolution time: How quickly domain lookups are processed from different geographies, revealing potential delays in the earliest stage of a connection.
- TCP and TLS handshake latency: The speed of establishing secure connections, which can vary based on network conditions, certificate configurations, and endpoint responsiveness.
- Routing to edge versus origin: Visibility into whether traffic is served from the CDN edge or passed through to the origin, and how that choice impacts latency.
- Regional routing disparities across ISPs and clouds: Insight into how performance differs by network provider and geography, critical for troubleshooting multi-cloud or global service issues.
- Full waterfall timing from agent to origin: A detailed breakdown of each stage in the request/response cycle, enabling granular root cause analysis.
These metrics provide more than just visibility. They offer actionable intelligence you can use to fine-tune architecture, enforce SLAs, and respond decisively when performance degrades.
End-to-End Visibility Speeds Up Your Response
When incidents happen, the difference between “we think” and “we know” can be hours of downtime and reputational damage. By combining inside and outside observability in one interface, APIContext integrates with both Hydrolix and TrafficPeak, Akamai’s managed observability service that’s powered by Hydrolix, to eliminate guesswork, end the blame game, and restore confidence in your IT operations.
With this integration, IT leaders gain the ability to see — in real time — exactly how internal systems and the customer experience align or diverge. That clarity empowers faster decisions, stronger collaboration, and a measurable reduction in the cost and risk of outages.
Next Steps
The APIContext integration is available for both Hydrolix and TrafficPeak.
- Interested in learning more about Hydrolix? Try a proof of concept or demo.
- Learn more about TrafficPeak.
