Notifications
The bell: what it carries, what it deliberately will not carry, and why a notification you dismissed came back — or did not.
The bell: what it carries, what it deliberately will not carry, and why a notification you dismissed came back — or did not.
The bell holds what needs a person. Not what the WAF handled — that is the point most worth understanding before anything else on this page.
What it will not tell you
It does not report blocks. A refused request is the product working; a bell that rang for each one would ring forty thousand times a day on a busy site and be switched off by lunchtime. What was refused, by whom, and what they were reaching for is the Daily Summary, which is a record you read when you choose to.
So the bell being quiet means nothing needs you, not that nothing happened.
Everything here is a condition that will not resolve itself: an agent that stopped reporting, a setting that cannot act, a decision waiting to be taken, a document nobody rebuilt.
Dismissing, and why one comes back
Every notification can be dismissed, and it stays dismissed while the facts behind it are the same.
Each one carries a fingerprint of those facts. The dismissal is recorded against that fingerprint, so:
- An agent that went offline, was dismissed, came back and went offline again is news again — the fingerprint includes when the episode started.
- An engine update dismissed at 3.2.6 returns when 3.2.7 is published, and not before.
- A condition that is simply still true does not come back. That is the point of dismissing it.
Several fingerprints are deliberately bucketed, so a dismissal is not undone by every small change: event backlogs in blocks of five thousand, suppressions in blocks of five hundred, learned-rule proposals in blocks of five. Four new proposals do not re-raise a line you have already read; the fifth does.
And two are deliberately permanent once dismissed — an agent with no GeoIP database, and a bot setting that cannot act. Both are standing conditions with no fact that moves, so dismissing one says "I know, I have decided", and there is nothing that would honestly bring it back. Inventing a timestamp for them would re-raise them on a calendar, which is noise wearing the clothes of news.
Several about the same thing become one line
Seven of them are per site or per agent, and the bell showed one copy each: seven identical lines reading Learned rules are waiting for a decision are not seven pieces of information.
They collapse into one line that names its members — "On shop, wiki and mail: …" — or names a few and counts the rest. A count is a worry; a list is a task.
A collapsed line offers the action for every member when they all ask for the same one, and the question says how many it will act on. If one of them fails, the line stays: an action that reached two agents out of three must not look like one that reached all three.
What each one means
Severity is the engine's own judgement of urgency, not a vendor's: critical is something not working, warning is something that will bite, info is a decision waiting.
The fleet
| Notification | What it means | What to do |
|---|---|---|
| Agent not reporting · critical | Missed its heartbeat. It is still enforcing the last configuration it received, but is not receiving changes and its events are not arriving | Check the host is up and can reach central on the API port |
| Nginx is not consulting this agent · critical | The agent is running and reporting, and no request has ever arrived from the nginx module. Traffic through that nginx is being served without being examined | Check the module is loaded, security_check is on, and the socket is owned by the user nginx runs as |
| Agent is not receiving configuration · critical | Its config pull is failing. Anything you change stops reaching it until it is fixed | Check it can reach central and that its API key has not been revoked |
| No request has reached this agent recently · warning | Either the site is idle, or nginx stopped consulting the agent — a module left unloaded does exactly this and leaves the agent looking healthy | Make a request to the site. If the figure does not move, traffic is being served without examination |
| Events are backing up on an agent · warning | Events are queued and not arriving. The queue has a ceiling, and past it they are dropped | Check it can reach central and that central is accepting events. Anything dropped is gone |
| Agent has no GeoIP database · warning | Country and network are blank on its events, country rules match nothing, and none of it reports an error | Install a database, or treat its geography as missing rather than as zero |
| Urgent package updates available on the nodes · warning | Packages on the edge nodes themselves have fixes, against the Debian security tracker | Vulnerabilities |
| Agent waiting for approval · info | It enrolled and is not yet active. It receives no configuration until approved | Approve it, or revoke it if you did not enrol it |
| Engine update available · info | A newer engine than this one has been published | Open the notification to install it. The agent downloads, verifies the checksum and restarts — traffic is unprotected for that moment |
Configuration that cannot do what it claims
| Notification | What it means | What to do |
|---|---|---|
| Traffic is being counted against the wrong tenant · warning | Requests for names nobody configured are landing on this site and inflating its figures | Add a default_server returning 444 on that listen address, and give any name that should be served a block of its own |
| Bot detection is on, but the bad-bot list does nothing · warning | In that combination the engine skips the shipped patterns entirely — nothing is recorded and the reconnaissance warning has nothing to see | Switch on bad-bot blocking, or disable individual patterns instead |
| A bot setting is enabled but cannot act · warning | Settings that need the JavaScript challenge are on while the challenge is off, so the console claims they are active | Switch on the challenge, or switch off what depends on it |
| CRS ruleset feed is not updating · warning | An agent's own six-hourly fetch has been failing. Its attack rules are as old as its last successful fetch | Check it can reach the feed. Refreshing on the dashboard does not reach an agent |
| The managed ruleset mirror has not been rebuilt · info | Nobody rebuilt the published document. The agents are fetching it successfully, so nothing else would say anything: what they fetch is simply old | Run tools/update-feed.sh --push, or find out why the timer stopped |
| A published rule document cannot be read · warning | The feed answered with something that is not a valid document. Every node reads the same one, so they are enforcing the last copy they did read, with nothing saying so | Check the repository is reachable and the document is valid JSON with a build_datetime |
Decisions and findings
| Notification | What it means | What to do |
|---|---|---|
| A site is being mapped out · warning | One actor working through an application's surface rather than attacking one spot | Look at what they reached for. If it names something you had forgotten was exposed, this is the window where closing it is still cheap |
| A verified crawler is being refused · warning | Requests claiming to be a crawler that passes reverse-DNS verification were refused | Look up the addresses. Consumer or hosting networks mean something is forging it and this is working as intended |
| Automatic suppressions firing in volume · warning | Rules are being suppressed for a lot of traffic. Each suppression is a rule switched off for what it covers | False Positives |
| New findings about software on the proxied sites · varies | Vendors published advisories against software found behind the proxy | Read what the vendor said; each finding links to its source |
| Software in use that will not be fixed · warning | A component whose vendor has withdrawn it or dropped its branch. No update exists — it clears by replacing or removing | Vulnerabilities |
| Learned rules are waiting for a decision · info | Rules proposed from a site's own traffic. Nothing is being enforced from them | Accept the ones you recognise; an accepted rule runs log-only first and the decision is reversible |
| False-positive exclusions no longer used · info | Exclusions that have allowed nothing in over 30 days. Each one switches a rule off for the traffic it covers | Delete the ones nothing needs. The hit counters are what make that safe to judge |
| What happened yesterday · info | The daily record is ready | Daily Summary |
Where to go next
| What was refused, as a record | Daily Summary |
| The fleet, and an agent's own state | Agents |
| A rule that was wrong | False Positives |
| Rules proposed from your traffic | Learned Rules |
| What is vulnerable in what is exposed | Vulnerabilities |