App connectors provide the link to internal applications. As long as they run, nobody notices them, and that is what makes their failure awkward: it is not noticed but reported, usually by users who do not know what is behind it. Connector Status Overview makes the state of connectors visible before the effect reaches the user. The gain is not only time but sequence: you know about the disruption before you are asked about it.
The invisible component
App connectors are the link between the Zscaler environment and the internal applications that should be reachable through it. They work unobtrusively and give no reason to think about them in normal operation.
That unobtrusiveness has a downside. When a connector fails, it is not the connector that disappears from view but the application behind it. The user reports that an application is unreachable. That a connector is the cause comes at the end of the investigation, not the beginning.
Why sequence matters
The difference between "we know and are working on it" and "thanks for the tip, we will look into it" is considerable for the user. The first sentence shows an organisation in control. The second shows one using the user as its sensor.
There is also a time gain. A reported outage starts with a description from the user's perspective that has to be translated first. An observed outage starts with the finding.
What Connector Status Overview shows
Connector Status Overview makes the state of app connectors visible in one place. You see which are running and which are not, without anyone having to ask.
For the service desk this changes daily work at an unremarkable point: when a report says "application X is not working", a glance at the connector state takes seconds and immediately includes or rules out one of the most common causes.
Redundancy is no substitute for visibility
Many environments run connectors redundantly, so that the failure of a single one causes no immediate disruption. That is right and important, but it is no substitute for visibility.
An unnoticed failure in a redundant setup means the redundancy has been consumed without anyone knowing. The next failure then hits an environment with no reserve. Visibility is most valuable precisely where the first failure has no consequences.
In a redundant setup the first connector failure causes no disruption. It merely consumes the reserve. Anyone who does not see it learns about it at the second failure.
The notification reaches your phone, warnings and all-clear
Visibility in the console helps as long as someone is looking. At night, at weekends and during meetings, nobody is looking. CentaurNexus therefore does not wait for someone to open the overview but reports of its own accord: through the notify app, on the device you carry anyway.
Checks run every three minutes. If a connector fails, a notification goes out. When it comes back, a notification goes out as well, and it states how long the outage lasted. That second direction is the part monitoring tools tend to leave out: they report the problem and stay silent on the all-clear. Anyone wanting to know whether things are running again has to check for themselves.
Notifications work on two levels: individual app, cloud and service edge connectors, and additionally the group they belong to. For the overview in the app the group matters; for troubleshooting, the individual connector does.
Three things are deliberately built to keep notifications useful. A brief blip triggers nothing; only a disruption outlasting a grace period does. When monitoring first starts, no notification is raised merely because a state is observed for the first time. And if the connection to the tenant is down altogether, per-connector notifications are suppressed rather than sending a hundred messages at once.
The everyday difference is sequence. You learn about the disruption before the first user notices it, and you learn about the all-clear without having to ask.
Frequently asked questions
What is an app connector?
An app connector provides the link between the Zscaler environment and an internal application, so that it is reachable through ZPA without being exposed on the network.
What does Connector Status Overview show?
The state of app connectors in one place: which are running and which are not. An outage becomes observable instead of surfacing through a user report.
Why is redundancy not enough?
Because an unnoticed failure in a redundant setup consumes the reserve without anyone noticing. The next failure then hits an environment with no buffer.
What does this give the service desk specifically?
When a report says an application is unreachable, one of the most common causes can be included or ruled out in seconds, instead of being found at the end of the investigation.
How does this relate to a monitoring system?
It complements it. The state becomes visible where Zscaler operations already take place, while an overarching monitoring system continues to serve its own purpose.
Sources
See the workflow in context
Pick the matching role in the demo launcher. The demo uses prepared sample data.
Open demo launcher