Is Zscaler Down? How to Check Zscaler Status and Keep Users Working
.jpeg)
Quick answer: To check whether Zscaler is down, go to the Zscaler Trust Portal at trust.zscaler.com, which Zscaler describes as its source for real-time service health, uptime status, and planned maintenance. If the Trust Portal looks green but users still can't browse, the problem is usually closer to home: the Client Connector on the device, the local network, or a single site. The triage table below helps you tell which in a few minutes.
The helpdesk queue fills up fast when web access breaks. Half the tickets say "the internet is down." The other half say "is Zscaler down?" This runbook is for the admin who has to answer both, quickly and correctly, and then tell everyone else what's happening.
Last updated: November 2026
Step 1: Check Zscaler status
Start with the vendor's own status page, not a third-party tracker. Zscaler's Trust Portal is listed on zscaler.com as the place for real-time service health, uptime status, and planned maintenance notifications. Zscaler has also described it as covering incidents, security advisories, and historical data, with the option to subscribe to notifications for the events you care about.
Two things to do before you need them:
- Subscribe your SOC or NOC to Trust notifications so the first alert doesn't come from a user.
- Know which Zscaler cloud your tenant is on. Status is reported per cloud and data center, so you need to know which one applies to you.
Also check planned maintenance. A scheduled window can explain a blip that looks like an outage.
Step 2: Triage client, network, or cloud
Most "Zscaler is down" tickets aren't a Zscaler cloud outage. Narrow it down by asking who is affected and where.
| What you see | Likely cause | First check |
|---|---|---|
| One user, everywhere they go | Client Connector on that device | App status and logs on the device; see our Client Connector troubleshooting guide |
| One user, only on hotel or airport Wi-Fi | Captive portal blocking the agent | Captive portal and fail-open settings |
| Everyone at one office | Local network, ISP, or tunnel to Zscaler | Office uplink and tunnel health |
| Many users, many locations, same region | A Zscaler data center or cloud issue | Trust Portal for your cloud and nearby data centers |
| Everyone can browse, but one site fails | That site, its category, or SSL inspection | URL category and certificate errors; see Site Review and root certificate guides |
| Browsing works but feels slow | Latency from distance to the nearest point of presence | See what the Zscaler speed test measures |
Step 3: Decide on fail-open vs. fail-closed
When the security path breaks, you choose between availability and enforcement. Fail-open lets traffic flow without inspection so people keep working. Fail-closed blocks traffic until inspection is back, which protects data but stops the business.
Zscaler documents fail-open settings for Client Connector. Review yours now, not during an incident, and get sign-off on three questions:
- Which user groups fail open, and which fail closed?
- Who has authority to change the setting during an incident?
- What compensating controls apply while traffic isn't inspected?
Write the answers into your incident plan. A fail-open decision made at 2 a.m. without a policy behind it is how audit findings start.
Step 4: Tell users what's happening
Silence generates more tickets than the outage itself. Post one message early, then update on a fixed schedule. Here's a template you can paste into Slack, Teams, or email:
"Heads up: some people are having trouble reaching websites and SaaS apps. We've confirmed the issue is with [our web security provider / the office network / a specific site] and we're working on it. You don't need to open a ticket. If you're on hotel or public Wi-Fi, disconnect and reconnect first. Next update at [time]."
Close the loop when it's resolved, and say what you're changing so it doesn't happen again.
Step 5: Review after the incident
Once service is back, capture the timeline, the user impact, and the decision you made on fail-open. Then ask the bigger question: how much of your business depends on one vendor's cloud being healthy for every web request? We cover that argument in Zscaler outage history and the shared control plane.
How this looks on an on-device SWG
When inspection runs on the laptop, a cloud incident doesn't have to stop browsing. dope.security performs SSL inspection and policy enforcement on the device, so traffic goes straight to its destination with no stopover in a vendor data center. dope.console also includes a fallback mode with cached policies, so endpoints keep enforcing the last policy they received.
For the rest of the day-2 work behind a cloud proxy, see Running Zscaler in 2026: the admin's day-2 guide.
Frequently asked questions
How do I check if Zscaler is down right now?
Go to the Zscaler Trust Portal at trust.zscaler.com. It shows real-time service health, uptime status, and planned maintenance. Check the cloud and data centers your tenant uses.
Why can't I browse when the Trust Portal shows no outage?
The issue is usually local: the Client Connector on your device, a captive portal on public Wi-Fi, your office network, or a single site's category or certificate. Use the triage table above.
Should Zscaler fail open or fail closed?
It depends on the user group and the data they handle. Many teams fail open for general staff and fail closed for high-risk groups. Decide in advance and document who can change it.
Can I get notified about Zscaler outages?
Yes. Zscaler's Trust Portal supports notifications, so subscribe your SOC or NOC before the next incident.
Related reading
- Running Zscaler in 2026: The Admin's Day-2 Guide
- Zscaler Outage History in 2026
- Zscaler Client Connector Troubleshooting: 8 Errors Admins Hit Most
- Zscaler Speed Test: What It Measures
Want web security that keeps working when a cloud doesn't? Book a 20-minute demo.
.jpeg)
.jpeg)
