Traffic

Dashboard

Request volume, a stacked passed / challenged / blocked chart over the last 24 hours, and a per-site breakdown of each site's mix.

The charts are filters. Clicking a bar or a slice opens Traffic Monitor already narrowed to what the chart was drawn from — the reader's next question after seeing a spike is "show me those", and it should not mean rebuilding the filter by hand.

Traffic Monitor

Every proxied request, with:

• the site, the client address and its country
• the method and path
• the verdict, and for anything the rules touched, the score and every rule that contributed to it
• the response status and how long it took

Filter by site, verdict and time window. The per-hour chart narrows to the same filter, so a bar and the rows under it can never disagree.

Rows are written in batches, a moment after each response, so a request that has just been answered can take a fraction of a second to appear. A request is never held up to record it: if requests arrive faster than rows can be written for long enough to fill the queue — tens of thousands a second, which is an attack rather than traffic — the rows that do not fit are dropped, and the journal says how many (see Troubleshooting).

Verdicts

Verdict	Meaning
PASSED	Nothing matched, or nothing that scored
SCORED	Something matched but stayed under both thresholds. Forwarded
CHALLENGED	Sent a CAPTCHA
BLOCKED	Refused with 403
WOULD BLOCK	The policy is in DetectionOnly; this would have been blocked
WOULD CHALLENGE	The policy is in DetectionOnly; this would have been challenged
SIGN-IN	The site asks for a sign-in and the request had none: it was sent to the sign-in page

A signed-in visitor's name is shown under the client address.

SCORED is deliberately not called "detected". Detected reads as stopped, and these requests were forwarded to your application exactly as they were.

Acting on a row

A blocked row carries the rule that blocked it, and a button that excludes that rule for that client on the site's policy — every site using it, which the confirmation states. That is the fastest honest answer to a false positive: keep the rule for everyone else, and stop it refusing the caller it was wrong about.

Beside the client address, every row also offers Block and Allow, which put that address on one of the site's policy's IP lists — refused before any rule runs, or waved past every check, on every site using the policy. A row whose client is already listed shows a badge instead, so you cannot add it twice. A row whose site has no policy offers none of the three.

The three are different sizes and the row keeps them legible: excluding turns one rule off for one client on one site, blocking refuses that address everywhere, and allowing skips every check for it everywhere. The widest is not the easiest to reach by accident — blocking asks for confirmation.

Retention

Traffic history is kept forever by default. Set a window under Settings → General and older events are pruned at startup and hourly.

The Settings page shows how many events are stored, so the setting's effect is concrete rather than theoretical.

What is not recorded

Traffic history holds the method, host, path, country and verdict — no headers and no bodies. That keeps the database bounded and keeps request contents out of it, but it means a new rule cannot be replayed against past traffic to see what it would have matched.

The path is stored without its query string. The flow log sends the full path and query to a collector, so that is where to look when the query string is what you need.

Beyond the appliance

Traffic Monitor is bounded by what an appliance should hold. For longer history, several appliances charted together, or alerting, send flow logs over syslog to a collector such as EasyLog — one line per request, with the same verdict, score and rules.