Is it Zscaler or the Wi-Fi? Root cause analysis in minutes

A Teams call stutters, and the first sentence in the ticket is almost always the same: "It must be Zscaler." Often that isn't true. But proving the opposite costs the help desk hours. There is a faster way.

Every IT team knows the scene. An employee calls, the video call stalls, the cloud app loads sluggishly. Because Zscaler sits inline in the data stream as a security layer and inspects all traffic, it is the most visible element of the chain, and therefore the first suspect. The reflex "it's Zscaler" is understandable, but it is a guess, not a diagnosis.

In reality, the cause is just as often an overloaded home Wi-Fi, a weakening ISP link, a CPU-heavy laptop, or an application that is itself having problems right now. The catch: the help desk first has to laboriously prove this. And until the proof is in, the suspicion hangs on the security gateway, which objectively does nothing wrong.

Why the blame question is so expensive

The classic process eats time in several places at once. First-level takes the ticket but cannot view the network chain itself and escalates. Second-level opens several consoles: the ZDX dashboard, perhaps a separate network monitoring tool, the device inventory. They correlate timestamps by hand, check whether a policy took effect at the time of the incident, and finally formulate an assessment they have to explain to the user.

Each of these handovers costs minutes to hours. And because the suspicion stands in the room without a hard finding, in case of doubt it lands with the security team, which then in turn has to prove that everything is running correctly. In the end it was the home-office Wi-Fi, but four people worked on it.

Zscaler already provides the data: ZDX

Zscaler Digital Experience, ZDX for short, measures the digital user experience end to end. It captures device metrics (CPU, memory, Wi-Fi signal), the local network link, the path via the internet provider, and the path through the Zscaler cloud to the target application. The ZDX Deep Trace shows every single hop with latency and packet loss. So the information on where exactly it is stuck is technically available.

The catch is not the data, but access and interpretation. The Deep Trace is a tool for specialists. It shows raw values across the entire path, but it does not say in a single sentence: "The user's Wi-Fi is the bottleneck, Zscaler is unremarkable." It is precisely this translation from measurement to statement that is the step that eats time in day-to-day work and requires admin rights the help desk often does not have.

Connectivity Triage Map: pull the chain together, name the cause

This is where Connectivity Triage Map from CentaurNexus comes in. The module pulls together the complete ZDX chain via the official Zscaler OneAPI and supplements it with the current policy status for the affected user and application. From these signals it forms a plain-language verdict: the cause lies with the ISP, the Wi-Fi, the device, or Zscaler.

The difference is not access to new data, but the diagnosis instead of the raw data. Instead of opening five tabs and comparing timestamps, the agent sees a named finding and below it, expandable, the Deep Trace evidence hop by hop. Those who want to check more deeply see the chain; those who only need to act see the verdict.

Plain language, also for first-level

The practical lever lies in who can run the analysis. Because Connectivity Triage Map phrases the result in understandable language, not every case has to escalate to a network specialist. A first-level agent reads "bottleneck in the local Wi-Fi, Zscaler unremarkable" and can give the right recommendation directly: move closer to the router, check bandwidth, relieve the device. The escalation is avoided in exactly the cases where it would never have been necessary.

The finding as evidence

An often underestimated point: if the cause lies outside one's own sphere of influence, such as with an internet provider or a home-office connection, IT needs solid proof to hand the topic on. An exportable Connectivity Triage Map finding with Deep Trace evidence is exactly this proof. It documents in a traceable way at which point of the chain the latency or packet loss occurred, and takes the speculation out of the discussion.

CentaurNexus separates tenant contexts, assigns permissions by role, and logs workflows in a traceable way. The help desk sees its authorized scope without broad Zscaler admin rights. For EU customers, production operation runs entirely on STACKIT in the EU; privacy and data paths are documented in the privacy notice.

ZDX and NexusAgent complement each other

ZDX provides digital-experience context across application, network path and device. NexusAgent adds the endpoint signals needed for a supported CentaurNexus workflow when that information is not available through OneAPI.

The Cause Map connects available signals into a traceable cause-and-effect chain. It shows whether the strongest indication lies with the device, local network, Zscaler path or application. Source, data age and coverage remain part of the result.

A finding must lead to the next action

A diagnosis becomes useful to the help desk when it explains the next review step. A local Wi-Fi signal requires a different action from an unavailable App Connector or a central service issue. The operator sees the reasoning and can resolve or hand over the case deliberately.

Acceptance testing covers complete, partly available and deliberately missing sources. The Cause Map therefore remains understandable when a tenant does not provide every ZDX or agent source.