The threat centre
Read what was refused, find an incident, export — and what we never keep.
4 minUpdated
Every refused visit is listed there: what it asked for, where it came from, and which rule stopped it. Seeing some is normal — every public site receives attempts constantly, from plain automated scans to targeted attacks.
The period
The selector at the top (7, 30, 90 days or all history) applies to both the counters and the table. So the two always show the same window: if the cards say 400 threats, the table below holds 400.
Reading a row
Date, attack type, source address, HTTP method, and the outcome. The magnifier icon opens the full detail: address requested, rule triggered, offending field, retained headers and incident reference.
"Blocked" and "Detected" are two different figures
A detected threat was seen and logged, then passed on to your server: that is what observation mode does. A blocked threat was refused. A gap between the two is expected if one of your sites is in observation.
The incident reference
When a visit is refused, the page shown to the visitor discloses nothing: not the rule, not the attack family, not the pattern — those are evasion hints handed to an attacker. It shows only an incident reference. A wrongly blocked customer gives it to you, you search for it here, and you land on the exact row.
What we never keep
What the visitor submitted is never stored. We show the rule triggered and the name of the offending field, never its value. The reason is simple: on a login form, keeping the offending field would also keep the password typed right beside it. This is a contractual commitment, not a technical preference.
How long history is kept depends on your plan. The CSV export covers the displayed period, for a spreadsheet or an audit.
This page did not answer your question?
Contact us