ZPA war-room ladder — Connection Status + Policy + Connector

1. Why a green connector is not the ticket

Operators collapse five ZPA failures into one sentence: “HR is down, restart the connectors.” The laptop never attached to a Service Edge. Access Policy never allowed the contractor. The Server Group points at a different App Connector Group. The connector is up and the application health is Down. The user is on Browser Access with a posture rule that can never match. Those are five first clicks.

This page is the night-shift ladder for one private-app transaction. Lesson 13 taught which log store to hunt. The evidence desk taught five proof tools across ZIA and ZPA. Here you stay inside ZPA and ZDX and you refuse to name an owner until a named field on a UTC timestamp says so.

Hero · five rungs, one ticket

2. Mental model — five rungs

Memorise five named objects before you click. Each rung is allowed to prove one thing. Over-claiming a green tile is how you restart a healthy pair at 02:00 and miss the deny.

3. Decision flow — symptom → first rung

Flowchart first. Do not open the policy editor, and do not systemctl restart zpa-connector, until a diamond says so.

Path · prove before you change

4. How to choose — first tool + proof field

Print this next to the ZPA Admin Portal. If you cannot recite the proof field, you are not ready to change a rule or a VM.

5. Runbook Side A → B → C

Side A proves the session. Side B proves the member and the rule. Side C proves the clientless path and the hop the user felt. On a messy Sev-2, do them in this order until a field lights up.

Side A — User Activity, then User Status

1. Write the control sample before you open Admin

   User, destination FQDN, TCP/UDP port, UTC window, Client Connector vs browser. A screenshot of a green icon is not a sample. Official: Accessing User Activity Diagnostics.

2. Open User Activity, not the App Connectors page

   Path: Logs → Insights → Diagnostics. From Log Type, select User Activity. Filter Username + Application Segment + time. A private FQDN will not appear as a ZIA URL Category hit. Live events, if you need them in the same minute: Logs → Insights → Live Logs.

3. Read Connection Status, then Policy, then Connector

   Session status codes appear on the User Activity Diagnostics page (Understanding Private Access Session Status Codes). LSS User Activity fields for the same session include ConnectionStatus, Policy, Connector, Application, Server, InternalReason, Host, ServicePort.

4. If there is no User Activity row, switch to User Status

   Same Diagnostics page, Log Type = User Status. Official Connection: Status Code values include Authenticated (including re-auth), Authentication Failed, and Disconnected. That answers “did Client Connector attach to a ZPA Service Edge?” It does not answer “did HR load.” Also read Client Type — Branch Connector, Zscaler Client Connector, Client Connector Partner, Web Browser, Web Browser Unauthenticated, ZIA Inspection, or ZIA Public Service Edge.

Path:            Logs → Insights → Diagnostics
Log Type:        User Activity
Username:        contractor@lab.example
Application:     HR-Prod
Quote:           Connection Status + Policy + Connector + Server
If empty row:    Log Type = User Status
                 Authenticated / Authentication Failed / Disconnected
If ID = 0:       NO_CONNECTOR_AVAILABLE | APP_NOT_REACHABLE | INVALID_DOMAIN

Side B — App Connector health, then Access Policy

1. Prove the member exists in the bound group

   Path: Infrastructure → Private Access → Component → App Connectors. Confirm Status is Enabled, the row sits in the intended App Connector Group, and connections are up. Optional dashboard: Analytics → Switch to Existing Reports → Private Applications → App Connectors (and Health). A healthy VM in a different group does not serve HR.

2. Open App Connector Status, filter Disconnected

   Official Troubleshooting App Connectors: Logs → Insights → Diagnostics → Log Type App Connector Status → Add Filters → Connection: Status Code Equals Disconnected → Apply. Read Disconnect Time. Do not restart the pair that stayed Connected through the window.

3. Split NO_CONNECTOR_AVAILABLE from APP_NOT_REACHABLE

   NO_CONNECTOR_AVAILABLE + Connector ID 0 = Central Authority could not pick an eligible member (wrong group, all members Disconnected, group disabled, or members paused for upgrade). APP_NOT_REACHABLE = a connector was selected and still could not open the application. Health Reporting on the Application Segment is Continuous, On Access, or None; the connector then paints the app Up or Down. Source: Understanding Health Reporting; Viewing the Health Dashboard.

4. Only then open Access Policy

   If User Activity already named a Policy, that is the rule you edit — not a new Allow at the bottom. Official current path: Policies → Access Control → Private Applications → Access Policy. Classic ZPA Admin still says Policy → Access Policy. ZPA is default-deny until a rule explicitly allows. Evaluation is most-specific Application Segment, then top-down first-match. List a Block above a broader Allow. Criteria (SAML, SCIM, posture, Client Type, Trusted Network) are AND across types and OR inside one type.

Side C — Browser Access, then the ZDX hop

1. Confirm Client Type before you blame posture

   Browser Access lets a user authenticate and reach an application over ZPA from a web browser without installing Client Connector (About Browser Access). On User Activity / User Status, Client Type is Web Browser or Web Browser Unauthenticated. Posture Profile and Trusted Network are ZCC-only. A rule that ANDs posture will never match a browser session — it is skipped, then default-deny.

2. Read the EUN code, not the Slack paraphrase

   Official: Locating Browser Access Error Codes. If the user hits a Browser Access-enabled application and fails, the end user notification includes the error code. Quote that code. Also confirm the Application Segment actually has Browser Access defined (Help also documents Policies → Access Control → Clientless → Browser Access for the clientless object). Browser Access LSS fields include ConnectionStatus — same discipline as User Activity.

3. Only if the session already succeeded, open Hop View

   ZDX does not invent Cloud Path for every private FQDN. If HR has no probe, Hop View is empty and you cannot prove a hop. Official: Evaluating the Cloud Path. ZDX traces the path and measures latency, packet loss, and jitter. Hop View and Command Line View both exist; errors show as icons (Cloud Path Errors). Quote the hop, not the headline score.

4. Treat Score as a pointer

   Understanding the ZDX Score: 0 (lowest) to 100 (highest). Score uses Cloud Path probe metrics — end-to-end latency, packet loss, hops. A 42 versus peers at 81 is a gap. It is not an Access Policy change and it is not a tenant Sev-1 by itself.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

ZPA-CC-01 — Empty User Activity (User Status first)

01:52 · P2. Contractor on a hotel network. Phone photo of a green-ish Client Connector icon. L1 drafted a new Access Policy Allow and a connector restart.

First tool: Logs → Insights → Diagnostics · Log Type User Activity, user + HR-Prod + last 30 minutes. The grid is empty.

Next tool: same page, Log Type User Status. Proof field: Authentication Failed (or no Authenticated event in the window). The device never built a ZPA session — token, enrollment, or Client Connector attach. There is no Policy to chase and no Connector to restart.

ZPA-CC-02 — Policy deny (Enabled is not an Allow)

02:08 · P2. Application Segment HR-Prod is Enabled. Finance opens hr.internal.example. The contractor cannot. Someone wants the Deny moved to the bottom “like a firewall.”

First tool: User Activity. Filter contractor + HR-Prod.

Proof field: Connection Status is the official block wording — the Private Access service blocked the request because the user isn’t allowed to access the requested application — and Policy = Block-Contractors-HR. That name is the ticket. If Policy is instead Allow-Finance-HR, first-match already fired the Allow above the Block — drag the Block above the Allow. Official Help: list the block rule before the allow. If Policy is empty and there is still a deny, you are on implicit default-deny: no Allow matched that most-specific segment.

ZPA-CC-03 — Connector ID 0 (the green pair is the wrong group)

02:24 · P1. Whole HR cohort failing after a Server Group edit. Mumbai App Connectors page is a wall of green. L1 wants both VMs rebooted.

First tool: User Activity. Proof: Connection Status = NO_CONNECTOR_AVAILABLE, Connector ID = 0. Official Troubleshooting App Connectors: ID 0 means the Central Authority could not resolve a connector — also seen with APP_NOT_REACHABLE and INVALID_DOMAIN.

Next tool: App Connector Status, filter Disconnected, plus the Server Group → App Connector Group binding. In the lab, HR’s Server Group still points at DC2-BLR-AppConnectors. Mumbai being green is a different object. If instead the bound members are Connected and health is Down, you are on APP_NOT_REACHABLE — the connector exists and the server is dark. That is a server / DNS / port problem, not a reboot of a Connected member.

ZPA-CC-04 — Browser Access (posture cannot match)

02:40 · P2. A contractor on a kiosk browser hits the Browser Access FQDN and gets an EUN. The Allow rule ANDs Posture Profile = Compliant-Win. Someone wants Client Connector pushed to the kiosk at 02:00.

First tool: User Activity / User Status Client Type = Web Browser. Official About Browser Access: no Client Connector install. Posture and Trusted Network have nothing to report, so the criterion is skipped and the rule never matches — then default-deny.

Proof field: the EUN error code (Locating Browser Access Error Codes) plus Client Type. Write a separate clientless Allow without posture, or send the user through ZCC. Do not “fix posture” on a browser that cannot run it.

ZPA-CC-05 — Session succeeded; the hop is the ticket

03:02 · P3. HR “the private app is slow” for one laptop. User Activity Connection Status succeeds; Policy = Allow-Finance-HR; Connector = mum-ac-01. Someone typed Sev-1 in the channel.

First tool: ZDX → that user → HR → Cloud Path → Hop View — only if a probe exists.

Proof field: the hop whose latency / packet loss jumped — often device → ISP, or Service Edge → app — plus the path-change time. Score 42 versus peers 81 is the pointer. It is not a new Allow and it is not a tenant outage by itself.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• Zscaler Help — Accessing User Activity Diagnostics (Logs → Insights → Diagnostics · Log Type: User Activity)
• Zscaler Help — Accessing User Status Diagnostics (Authenticated / Authentication Failed / Disconnected; Client Type)
• Zscaler Help — Understanding Private Access Session Status Codes (codes on the User Activity Diagnostics page)
• Zscaler Help — Understanding User Activity Log Fields (LSS: ConnectionStatus, Policy, Connector, InternalReason)
• Zscaler Help — Accessing Live Logs (Logs → Insights → Live Logs)
• Zscaler Help — Accessing App Connector Status Diagnostics (Log Type: App Connector Status)
• Zscaler Help — Troubleshooting App Connectors (Disconnected filter; Connector ID 0; NO_CONNECTOR_AVAILABLE / APP_NOT_REACHABLE / INVALID_DOMAIN)
• Zscaler Help — Understanding Health Reporting (application health Up / Down)
• Zscaler Help — Viewing the Health Dashboard
• Zscaler Help — About App Connectors (Status enabled/disabled; connection / health)
• Zscaler Help — About Access Policy
• Zscaler Help — Configuring Access Policies (Policies → Access Control → Private Applications → Access Policy; default block)
• Zscaler Help — Access Policy Deployment and Operations Guide (application not accessible → Access Policy / implicit block)
• Zscaler Help — About Browser Access (browser auth and access without Client Connector)
• Zscaler Help — Locating Browser Access Error Codes (EUN includes the error code)
• Zscaler Help — Understanding Browser Access Log Fields (ConnectionStatus)
• Zscaler Help — Evaluating the Cloud Path (Hop View; latency, packet loss, jitter)
• Zscaler Help — Cloud Path Errors
• Zscaler Help — Understanding the ZDX Score (0–100; latency, packet loss, hops)

Related: Lesson 13 · which log answers which ticket · Evidence desk · first tool + proof field · Lesson 10 · App Connectors · Lesson 11 · Access Policy · Lesson 9 · ZPA architecture · Zscaler practice dashboard