A read-only container next to your Wazuh 4.x manager that replays your own sample logs every night and tells you which custom rules no longer win, which rules went quiet and which active agents stopped alerting, as alerts on the dashboard your SOC already uses. For teams running Wazuh with custom rules, and for MSSPs watching several managers.
Supports Wazuh 4.x; tested on 4.14.7. Wazuh 5.0 is not supported yet. Nothing leaves your network: the licence is checked offline and the container never modifies the manager.
Download detection-watch-0.1.6.tar.gz, unpack it on the manager host and run:
tar xzf detection-watch-0.1.6.tar.gz && cd detection-watch-0.1.6
sudo ./quick-check.sh # Wazuh installed on the host
./quick-check.sh --docker <manager-container> # Wazuh in DockerIt runs one read-only scan of the last seven days of alerts with the Python that already ships inside every Wazuh 4.x manager, prints the rules that went quiet, the agents that went silent, the custom rules that never fired and any rules dropped at load, then deletes its temporary output. No container build, no API user, no licence, no email, no restart of the manager, no network calls. With --docker it copies its own code (about 65 KB) into the container's /tmp and removes it afterwards. On our rig (4.14.7, 132,731 alerts over seven days) it took 7 seconds.
What the quick check cannot do: without the API it cannot tell whether a silent agent is still reported active, it does not replay your samples through logtest, and it runs once. The nightly watch below does all three and writes each finding back as a Wazuh alert.
The container runs once a night (and on demand). Every finding becomes an alert in group detection_drift, rules 190001 to 190006, so it shows up in the same dashboard, filters and notifications as everything else. Each finding carries the rule or agent concerned, the daily counts behind it and the window it was measured over.
if_sid parent that does not exist), plus agent-queue-full alerts and dropped-event lines.Wazuh 4.14.7, scanned on 7 November 2026 over the previous seven days of alerts (128,901 of them; the scan took 3 s). The watch reported one rule that had fired on five of six days and then went quiet, and one agent reported active by the API, with a keepalive a few seconds old, that had gone from thirty and thirty-eight alerts a day to seven, then to none for a day. Neither would have raised anything on the standard dashboard: the manager was healthy and every agent was green.
The same silent agent, from the API's "active" to the level 10 alert in Wazuh: watch the 97-second walkthrough on YouTube (the presenter is AI-generated; the screens are from our rig).
One container, read-only mounts, one restart of the manager. Nothing is installed inside Wazuh except one rules file and one localfile block.
Download detection-watch-0.1.6.tar.gz (55 KB: Dockerfile, docker-compose.yml, the rules file, the quick check, the docs) and check it: sha256sum detection-watch-0.1.6.tar.gz must print 7d560b93…94b620 (full hash). Unpack it on the manager host and run docker compose up -d. The container is built from source on your host, runs as a non-root user on a read-only filesystem with all capabilities dropped.
Mount /var/ossec/logs and /var/ossec/etc/rules read-only. The only directory it writes is its own output directory.
Create one API user with read access and logtest. The client calls three endpoints and refuses every other path in code.
Build the sample corpus from your own alerts: docker compose run --rm detection-watch samples --from-alerts --out /var/detection-watch/out/samples writes one scrubbed log line per rule that fired, with the rule id it should hit, and skips rules that need several events; then point samples_dir in config.json at that directory (or copy the files into ./samples). Edit the result if you like; it is plain text.
Copy the supplied rules file into /var/ossec/etc/rules, paste one <localfile> block into ossec.conf, restart the manager. The findings now arrive as alerts.
/var/ossec. Everything from the manager is mounted read-only.read_only: true and keeps running.USD 29 per manager per month
Or USD 290 per manager per year. One unit is one Wazuh manager; an MSSP watching five customer managers from one installation buys five. The licence is a file emailed to you; renewals send a fresh file.
14-day trial: one manager, free, no card. Request it with the form below; the licence file arrives by email and the download above is the same for trial and paid.
Card checkout by Paddle.com, our reseller and merchant of record; taxes are calculated at checkout. The licence file is emailed to the address you enter at checkout, usually within a minute.
The licence is sent to the address you enter, not shown on this page: delivery to the mailbox is how the address is verified. One trial per address.
Wazuh 4.x only; tested on 4.14.7. Wazuh 5.0 is not supported in this release. Replay uses the manager's own logtest API, so it inherits that API's limits: what logtest cannot reproduce, the watch cannot check. A rule written for a quarterly event is not dead after one quiet day; that is why the measured window is printed with every finding, and why the quiet threshold is yours to set. This is v0.1, early access: the finding kinds above are what it does today, and the example on this page comes from one rig of ours, not from a customer's production environment.
No. The container runs on your host, reads mounted files and talks to your own API. We never see it, and it never contacts us.
No. There is no telemetry, no licence server and no update check. The only connection it opens is to your manager's API. You can confirm this by running verify-licence on a host with no internet.
Not yet. The analysis engine and the rule format change in 5.0, so the watch is on the roadmap after 5.0 GA. If you are planning that move, the free Wazuh rule precheck reads your 4.x rules and tells you what 5.0 will do with them.