Security → Blocks

Blocks is the per-site view of everything the security pipeline stopped. Each layer — the WAF, the rate limiter, Patchstack, login lockout, and the edge IP-reputation layer — reports what it rejected, and Blocks collects all of it into one timeline, attributed to the control that did the blocking. It answers the question the rest of your analytics can’t: what tried to get in, and what stopped it?

Find it under the Security tab of any site in the dashboard.

The Blocks page for a site in the app.managed.dev dashboard: a block-volume-over-time chart at the top, a legend separating blockers (WAF, rate limit, Patchstack, login lockout, IP reputation ban), and a table of recent blocked requests below — each row showing the timestamp, source IP, blocker, matched rule, and request path.

What each blocker means

Blocker	Layer	What it caught
WAF (coraza)	Site runtime	A request matched an attack pattern — injection, XSS, traversal.
Rate limit	Site runtime	A client exceeded its request budget and was throttled.
Patchstack	Edge	A request matched a known plugin/theme CVE exploit signature.
Login lockout	Site runtime	A source hit too many failed logins on wp-login.php.
IP reputation ban	Edge	An IP with a bad reputation was refused by the edge (CrowdSec).

The edge layers (Patchstack and IP-reputation attribution via CrowdSec) act before a request reaches your site at all; the runtime layers (WAF, rate limit, login lockout) act at the application. Seeing them side by side tells you whether you’re fending off broad internet scanning at the edge or targeted attempts against one site.

Block volume over time

The chart at the top of the page plots block volume, broken down by blocker. Read it for shape, not just total:

• A flat, low baseline across all blockers is normal background noise — the internet scanning every public site.
• A spike in Patchstack blocks usually means a freshly disclosed CVE is being scanned for across the web. You’re already protected; confirm the affected plugin is updated anyway.
• A spike in login-lockout blocks against one site is a credential-stuffing run. Confirm login lockout is doing its job and consider an IP allowlist on wp-admin.
• A spike in rate-limit blocks can be an attack or a misbehaving integration of your own — check the source before assuming malice.

Blocked requests stay out of Requests

Blocked requests are deliberately kept out of the normal Requests view. Attack traffic is high-volume and would otherwise drown out your real visitors, skewing status-code ratios, top-paths, and latency percentiles. So the two views are clean by design: Requests is the traffic you served, Blocks is the traffic you refused.

Trace sampling is per-site / per-plan

How much request detail is retained for tracing is configured per site and per plan, so higher-tier plans and sites under investigation can keep richer data while quieter sites stay efficient. This sampling applies to the traces and request data, not to block events — blocks are recorded as security events on their own path. See traces for how sampling affects what you can drill into.

How to read and act on a block

1. Start with the chart. Identify which blocker spiked and when.

2. Filter the table to that blocker and timeframe. Look at the source IPs — one noisy IP is a targeted attempt; a wide spread is distributed scanning.

3. Open a block for detail. WAF blocks show the matched rule and the offending request; Patchstack blocks show the CVE signature; IP-reputation bans show the reputation scenario.

4. Decide. Genuine attack traffic needs no action — it was stopped. If you suspect a false positive (a legitimate request being blocked), grab the block ID and report it; the team adds a targeted exclusion rather than weakening the ruleset. See WAF tuning.

Who can see Blocks

The Blocks view is available to site_manager and above — site_manager, admin, and owner. An observer sees observability data but not the security-block detail, and billing has no site access. See teams & roles for the full role matrix.

site_manager+ visibility keeps attacker IPs and matched-rule detail scoped to the people responsible for the site.

Next steps

RequestsThe clean view of traffic you actually served, with blocks excluded.

WAF & rate limitingTune the firewall and report a false positive using a block ID.

Security API referenceRead block events and security data through the public API.