Traffic Analytics
Configuration tells you what is allowed. Traffic tells you what is used. ZHERO pulls the real volumes onto the entity you are already looking at, over the last 30 days or the last 180, so that “this rule is probably dead” becomes a number.
It is for cleanup, capacity questions, and for anyone who has been burned by deleting something that turned out to be seasonal.
When to use it
- Before deleting or disabling anything. Zero traffic over 30 days is a hypothesis; zero over 180 is a decision.
- Validating a new rule. It went live last month: is it matching anything?
- Capacity and branch questions. Which locations carry the traffic, and which carry surprisingly much of it.
- Shadow IT and SaaS reviews. Which cloud applications are actually in use.
Where to find it in the UI
Traffic is fetched on demand, per entity, from the entity’s action menu:
- Fetch Web Traffic Data (30d)
- Fetch Web Traffic Data (180d)
- the firewall equivalents, where the entity carries firewall traffic
Once fetched, the volumes render on the entity card and drawer, and the 30-day numbers flow into the exports that carry traffic columns.
It is on demand by design: a traffic query is expensive, so ZHERO asks Zscaler for it when you ask for it, not continuously for every entity in the tenant.
What carries traffic, and over what window
| Entity | Web traffic | Firewall traffic |
|---|---|---|
| URL category | 30 and 180 days | |
| Cloud application | 30 and 180 days | |
| Location | 30 and 180 days | 30 and 180 days |
| Location group | 30 days | 30 days |
| Firewall rule | 30 and 180 days |
Policy rules (SSL inspection, URL filtering, cloud app, DNS, IPS, forwarding, file type, bandwidth, sandbox, DLP) carry related traffic: the traffic of the entities they reference, which is how a rule with no direct counter still tells you whether anything flows through it.
Locations are the entity where both views matter: web insights and firewall traffic are different questions, and a location can be busy on one and quiet on the other.
Step by step
- Open the entity you are considering, from a policy list, the Entities table or search.
- Open its action menu and fetch the window you want. Start with 30 days.
- Read the volume and the transaction count on the card.
- If it reads zero or near-zero, fetch 180 days before acting. This is the step that separates a dead rule from a quarterly one.
- Act: disable, delete, or leave it alone, through Pending Changes like any other change.
What to watch
- Quarter-end and seasonal traffic. A rule that looks dead across four weeks can carry the payroll run, the annual audit or a holiday campaign. That is the entire reason the 180-day window exists.
- Blocked counts are traffic too. A block rule with 1,200 hits is working, not idle.
- A location with far more traffic than its size suggests. Either a routing problem or something worth investigating on the endpoint side.
- Traffic against configuration. A category referenced by five policies and carrying no traffic at all is a cleanup candidate; so is one carrying traffic that no policy was supposed to allow.
Limits and notes
- The windows are mutually exclusive in a report. A sheet carries either 30-day or 180-day volumes, never both, so it is always unambiguous which window a number belongs to.
- Data comes from Zscaler’s own insights and logs, through your authenticated session, and is bounded by what your tenant retains and what your admin role can query.
- It is fetched, not live. The numbers on a card are from the moment you fetched them. Fetch again for a fresher view.
- Not every entity type carries traffic. The table above is the list; the action menu simply does not offer the option elsewhere.
- A 180-day fetch takes longer than a 30-day one. Use it where the decision justifies it.
FAQ
Why is traffic not just always there? Because querying it for every entity in a tenant, continuously, would be slow for you and heavy for Zscaler. On-demand fetching keeps the console responsive and the numbers meaningful.
Which window do the Excel exports use? 30 days, in the reports that carry traffic columns. The two windows never mix inside a sheet.
A rule shows zero traffic but I know people use that application. Check whether the traffic is being matched by an earlier rule. A rule below a broader one never sees the traffic, which is what unreachable policy detection is for.
Does traffic data leave my browser? It is queried from Zscaler through your session and rendered locally. See Privacy and data.
Can I compare two locations side by side? Export the locations report, which carries both web and firewall volumes per location with share percentages.
Related pages
- Export catalog: traffic columns in the reports
- Unreachable Policy Detection: the configuration reason a rule sees no traffic
- URL Inventory: zero-impact URLs, the configuration counterpart of zero traffic
- Troubleshooting Engine: traffic for one case rather than one entity
Next steps
- Pick the rule you have most suspected of being dead and fetch 30 days
- Fetch 180 days on the same rule before you touch it
- Do the same for a handful of URL categories you inherited
- Export the locations report and see where your traffic actually is