Dashboard
The first screen, and the one that is easiest to misread: what each figure counts, what it deliberately does not, and which question belongs on another page.
The first screen, and the one that is easiest to misread. What each figure counts, what it deliberately does not, and which question belongs on another page.

The figures across the top

They are all scoped to the period in the top bar, and all of them come from events — the decisions EdgeGuard recorded. That is the single fact the rest of this page follows from.
| Figure | What it counts |
|---|---|
| Requests acted on | Requests EdgeGuard recorded a decision for |
| Blocked Threats | Of those, the ones refused |
| Challenged | Captcha, JavaScript or managed challenges issued |
| Rate Limited | Requests refused for exceeding a limit |
| Unique Attackers | Distinct addresses among them |
"Requests acted on" is not your traffic. An allowed request produces no event unless Log All Requests is on in Global Settings, so on a default installation almost everything counted here was refused. The number is the WAF's workload, not the site's.
That is why there is no Block Rate on this page. Dividing blocked by a total that is the blocked count returns something near 100% on every installation — a figure that is arithmetically correct and says nothing. It was removed rather than relabelled: no label makes it worth a quarter of the headline row.

Disposition by Site is the same arithmetic per site, and behaves the same way: with Log All Requests off it reports what each site refused and withholds the share, because a share needs the allowed requests too. With it on, the columns mean what they say.
The question all of this looked like it answered — what share of my traffic is refused — is on Performance. That page reads the agents' own counters, which are the only ones that count the requests that passed through untouched. They are since each agent started rather than over a period, which is why the two pages do not share a row.
Vulnerability Exposure

Three populations, counted separately because they are assessed differently:
- Sites — the software behind the proxy, against its vendors' advisories.
- Edge nodes — the packages on the machines running EdgeGuard, against the Debian security tracker.
- Monitored servers — the same, for backends a collector reports on.
Two labels here are worth reading carefully:
"Could not be assessed and are not counted as clean." A node whose package list never arrived, or whose release no tracker covers, is reported as unassessed rather than folded into the clean count. "We do not know" and "nothing was found" are different answers and the tile keeps them apart.
"Unpatchable components." Software whose vendor has withdrawn it or stopped supporting its branch. No update exists, so the finding will not clear by patching — it clears by replacing or removing the component.
Full detail: Vulnerabilities.
The charts

Traffic Timeline plots decisions over the period. If the allowed series is flat at zero, that is Log All Requests being off, and the chart says so beside its title rather than leaving a reader to conclude that nothing was allowed.
Attack Distribution and Threat Severity break the same events down by rule family and by severity. The severities are the engine's own scoring — critical, high, medium — not a vendor's.
Top Countries and Top Sources & Targets name where traffic came from and what it was reaching for. Each row is a link into Security Events filtered to it, which is where the addresses and the EdgeGuard IDs are.
Bot vs Human and the challenge breakdown come from the bot classification. A site with nothing classified says so instead of drawing an empty chart.
Live Activity and Recent Events
The live panel streams decisions as they are made; the list beneath it is the most recent events with their rule and score. Both are a window into Security Events rather than a different source — open any row there to get the full detail, the matched text and the actions that turn one event into an exclusion or a rule.
When the page looks empty
In order of likelihood:
- The period. A one-hour window on a quiet site shows nothing. Widen it.
- The filters. Six of them live in the top bar and they apply here. See Top Bar and Filters.
- No agent is reporting. Check Agents: an agent that is not sending events produces an empty dashboard and no error.
- Nginx is not consulting the agent. The agent is healthy, the dashboard is empty, and traffic is being served without being examined. The bell says so when it detects it.
Where to go next
| Is the WAF slow, and what share of traffic is refused | Performance |
| Every decision, one row per request | Security Events |
| The shape of the traffic over time | Analytics |
| What was refused yesterday, as a record | Daily Summary |
| What is vulnerable in what is exposed | Vulnerabilities |