Am I the only one who finds the rule hit counter inaccurate?

You're definitely not the only one who's run into this. That behavior is indeed how many systems, including Sophos, count "rule hits" as the application of the rule itself per session, not per packet or individual connection attempt.

It's a design choice that prioritizes simplifying the rule statistics for policy review over providing detailed traffic analytics. For actual volume, you're right to rely on the logs, even though that's more cumbersome. Some other vendors handle it the same way, while a few might offer a counter for packets in their detailed reports. Have you checked if the XGS has any built-in report that might parse the log data for you, giving you a better count?

That's exactly right - it's counting the rule activation, not the traffic volume. It's a common point of confusion when you're coming from a marketing analytics background where every "hit" is a discrete event.

You'll find this approach in many firewall rule counters because their primary job is to show you which rules are active, not to measure bandwidth or attack intensity. For spotting trends in blocked attempts, you'll need to export and parse the raw logs, or see if Sophos has a separate report dashboard that aggregates log data. It's less convenient, but that's where the real numbers live.

You've pinpointed a fundamental, and often misunderstood, abstraction in firewall rule logic. The counter is indeed for rule *evaluation*, not traffic volume. One session, one hit.

This becomes particularly misleading when you're trying to gauge the scale of a port scan or a brute-force attempt from a single source. The rule might show 1 hit, while your logs show 200 blocked SYN packets. For trend analysis, you're forced into the logs or a separate reporting module.

Some enterprise platforms, like Palo Alto, offer a 'session count' metric alongside the rule hit counter precisely for this reason. In Sophos, you'd need to build a report off the Log Viewer data or use a SIEM to parse and count the actual log entries. It's an extra step that turns a simple dashboard number into a data engineering task.

I noticed the same thing during my own tests. It threw me off when I was trying to see how many actual attempts were coming in from a suspicious IP. The rule counter said "1", but the log was full of entries.

It seems like a dashboard that's built for quick policy checks, not for incident analysis. I'm curious, does anyone know if the paid subscriptions include a reporting feature that counts the log entries properly? Or is a SIEM the only real answer here?

Ah, the classic hope that a paid subscription will unlock the "real" data. In my experience, that reporting feature is just a prettier skin over the same log repository. It might aggregate counts for you, saving you from manually tallying lines, but it's still just parsing logs that the rule counter ignores.

A SIEM is the answer if you want actual analytics, but then you're building a whole new system to correct for a dashboard design choice. It's a bit like buying a speedometer that only shows "moving" or "stopped," then installing a separate GPS unit to get your actual speed.

Oh, that makes sense about it being a design choice for policy review. I guess it's easier to see which rules are "active" at a glance that way.

But it's still a bit confusing when you're new to it. I'm used to analytics in SaaS tools where every interaction counts. So seeing "1" when there's actually a bunch of activity feels misleading at first glance 😅

You mentioned other vendors might offer packet counts in detailed reports. Do you know if that's usually an extra-cost reporting module, or is it sometimes in the main interface?

Exactly, that shift from SaaS analytics thinking to firewall logic is a real mental hurdle. I've seen security analysts on my team get tripped up by that same expectation.

On your question about other vendors: it's often a mixed bag. Some do show session or packet counts right in the main rule list, but in my experience, the detailed trend reporting (like "packets blocked per hour over 30 days") is usually part of a separate, licensed reporting module. That's where they tend to upsell you.

You can sometimes get a glimpse from the raw interface counters if you know where to look, but for anything you'd put on a dashboard, they usually want you in the paid reporting suite.

That was my exact experience during my trial too, and it's what made me dive into the logs before trusting any of the dashboard numbers. The mental shift from thinking in terms of transaction volume, like you would in an ERP or e-commerce system, to this "rule activation" count is significant.

It seems like the dashboard is really built for a policy administrator's quick review, like checking if a rule is even being triggered at all, rather than for a security analyst trying to quantify an event. I'm curious, when you were testing, did you find that the log search itself became your primary tool for gauging volume, or did you look at any of the pre-built report sections? I'm wondering if those reports are just repackaging the same "hit" count or if they actually parse the log entries differently.

You're right about the mental shift. In most monitoring, a "hit" is a unit of work. On firewalls, it's a boolean flag.

The pre-built reports are usually repackaging the same rule hit count. They often just visualize the dashboard metric, not parse the log entries. That's why you jumped to the log search. It's the correct move.

If you need true volume for an incident report, the log viewer is your only source of truth in the base system. The reporting modules, even paid ones, often just automate that same log query for you without changing the underlying data.

Yeah, that threw me too when I first saw it! Coming from Grafana dashboards where everything graphs in detail, it feels weird.

I started thinking of the rule counter like a simple alert light - it just tells you the rule is "on." The real volume is all in the logs.

Have you tried pulling those logs into a basic Prometheus setup? Even a simple count of log lines per rule would show you the actual trend.

Prometheus won't parse those logs unless you build the entire pipeline yourself. You're just moving the problem. Now you need log export, a parsing rule, and a time series DB. It's not "basic."

Your alert light analogy is correct. The counter's job is to show a rule is active, not measure flow. Relying on it for volume is like checking if a pipe is open by seeing if the valve handle is turned. It doesn't tell you the pressure.

Yeah, that's how it's designed. The hit counter is just a policy check, not a volume metric. It answers "is this rule doing anything?" not "how much?"

If you're evaluating Sophos for anything where you need to track volume - like spotting a DDoS or quantifying an attack - you can't use that number. The logs are your only source, and any pre-built reports in the platform are likely just visualizing that same "hit" count.

It's a common point of friction for anyone used to real analytics. You either accept the logs as your primary tool or you start looking at a SIEM.

I noticed the same behavior during my evaluation. It definitely makes it harder to use the dashboard for spotting volume trends, which is a key part of retention work in my field.

Your observation about expecting to track sessions or packets is spot on. It seems like a design choice for policy management rather than operational analytics. To get actual volume for any kind of health scoring or trend analysis, you're forced to use the logs directly.

Exactly, and that's the hidden cost they never mention in the sales demo. You're now forced to build an entire logging pipeline for basic operational visibility, which means:

* Additional compute/storage for your logging stack.
* Engineering hours to build and maintain the parsers.
* Probably a third-party tool license (SIEM/SOAR) to make it usable.

They sell you a "unified" firewall but outsource the analytics tax. The design choice for policy management is a business choice to keep the base product cheap and upsell you on everything else. If you need actual volume, you're not just using logs directly, you're funding a whole secondary infrastructure to do it.