Key Takeaways
- Wazuh detects in near real time because the manager evaluates every decoded event against the ruleset the moment it arrives, rather than running scheduled batch queries.
- The pipeline has four stages: agent collection, manager decoding, rule matching and alert output. Each stage adds latency, and most tuning targets the decoding and rule phases.
- Active Response can act within the same second as detection: block an IP, disable an account or run a script, without waiting for an analyst.
- Latency is dominated by buffering and queueing, not by rule complexity. A backed-up analysis queue is the most common cause of slow alerts.
- Real-time does not mean instant. Realistic end-to-end detection on a healthy deployment is one to five seconds from event to alert in the indexer.
How Real-Time Detection Actually Works in Wazuh
Wazuh achieves real-time detection through a streaming architecture rather than a query-on-demand model. In a traditional log search tool, events are stored first and an analyst (or a scheduled job) queries them later. Wazuh inverts this: the manager evaluates each event against the full ruleset at ingestion time, so a match produces an alert before the event is ever written to long-term storage.
The flow begins at the agent. The Wazuh agent tails log files, reads the Windows event channel, watches file integrity and collects system inventory, then forwards events over an encrypted channel to the manager. On the manager, the analysisd daemon is the heart of real-time detection. It receives the raw event, passes it through pre-decoding, decoding and then rule evaluation.
Because analysisd holds the decoders and rules in memory and processes the event stream continuously, the time between an event occurring on an endpoint and an alert appearing is typically a small number of seconds. This is what makes Wazuh suitable for use cases like brute-force lockout, suspicious process execution and unauthorised configuration changes, where a delay of minutes would let an attacker progress.
The Analysis Pipeline Stage by Stage
Understanding where time is spent requires breaking the pipeline into its real stages. First, collection: the agent buffers events locally and ships them in batches to keep network usage efficient. The agent buffer is a frequent and overlooked source of delay, because under load the agent throttles its send rate to protect the manager.
Second, pre-decoding and decoding: analysisd extracts standard fields (timestamp, hostname, program name) during pre-decoding, then applies the matching decoder to pull out structured fields like source IP, username or URL. Decoders are evaluated in a tree, so a well-ordered decoder set is faster than a flat list of hundreds of unrelated patterns.
Third, rule matching: the decoded event is tested against the rule tree. Wazuh rules are hierarchical, where child rules only evaluate if their parent matched, which keeps evaluation efficient even with thousands of rules. Fourth, output: a matching rule above the configured alert level is written to alerts.json and forwarded to the indexer and to any integrations.
Need a Wazuh-Based Managed SOC?
Codesecure deploys and operates Wazuh, TheHive, n8n, Cortex and MISP as a managed SOC. 24x7 named analysts, detection engineering, tuned dashboards and audit-ready compliance reporting. No commercial SIEM licensing.
See Managed SOC →Where Latency Comes From
On a healthy deployment, rule evaluation itself is microseconds per event. The latency that operators actually experience comes from queueing and buffering, not from CPU-bound matching. The single most important internal structure is the analysis queue, which sits between the event receiver and analysisd.
When events arrive faster than analysisd can process them, the queue fills. Wazuh exposes the queue usage percentage, and a queue consistently above 90 percent means events are waiting, which directly adds to detection latency and risks dropped events. The agent buffer behaves similarly on the endpoint side: a flooding agent will throttle and its events will arrive late.
Network conditions matter for remote sites. Agents communicating over a constrained link to a central manager will batch more aggressively. For latency-sensitive estates spread across regions like India, Singapore and the UAE, a distributed collector or worker-node design keeps the agent-to-manager hop short and the analysis local.
Tuning for Low-Latency Detection
The first tuning lever is the number of analysis threads. By default analysisd uses a limited number of rule-matching threads, and on a multi-core manager increasing the thread count lets the queue drain faster under bursty load. This is configured in the internal options and should be matched to the available CPU.
The second lever is dropping noise early. Events that will never produce an alert still consume decoding and matching time. Filtering high-volume, low-value sources at the agent (for example, verbose debug logs) reduces the event rate analysisd must sustain, which keeps the queue empty and detection fast for the events that matter.
The third lever is the agent buffer configuration. For a server that generates security-critical events, raising the events-per-second buffer limit prevents the agent from throttling legitimate security telemetry during a spike. The trade-off is manager load, so buffer changes should go hand in hand with manager capacity planning.
Active Response: Acting in Real Time
Detection that only produces an alert still depends on a human to act. Wazuh Active Response closes that gap by executing a command on the agent or manager the instant a rule fires. Common patterns include adding an attacking IP to a firewall drop list, disabling a compromised user account, killing a malicious process or quarantining a file.
Active Response is bound to a rule ID or rule level, so you choose exactly which detections trigger automated action. Responses can be timed (block for a set duration then release) or permanent, and they can run on the specific agent that reported the event or on all agents. This is what turns Wazuh from a passive monitor into a system that contains an attack in the same second it is detected.
Care is required: an automated block driven by a noisy or poorly tuned rule can cause a self-inflicted outage. Production Active Response should be scoped to high-confidence detections, tested in a staging environment, and paired with an allowlist for critical infrastructure so the SOC never locks itself out.
Want Help With Detection Engineering?
Whether you run Wazuh in-house or want a fully managed service, our SOC engineers build custom rules, dashboards and integrations tuned to your environment. ISO/IEC 27001:2022 certified delivery, fixed-fee monthly retainer.
Talk to a SOC Engineer →Realistic Expectations and Measurement
Real-time in a SIEM context means seconds, not microseconds, end to end. A realistic figure on a well-sized, healthy Wazuh deployment is one to five seconds from the event occurring on an endpoint to the alert being queryable in the indexer, with the alert written to alerts.json slightly sooner. Active Response can fire even faster because it does not wait on indexing.
Measure detection latency deliberately rather than assuming it. A simple validation is to trigger a known rule (for example, several failed SSH logins) and compare the timestamp on the endpoint with the alert timestamp in the indexer. Track this over time, because latency degrades silently as event volume grows and the queue starts to back up.
If you operate Wazuh as part of a managed SOC, detection latency belongs in your service levels. Codesecure tracks queue health and detection latency as operational metrics, tuning thread counts, buffers and collector placement so that high-value detections stay in the one-to-five second band even as the estate scales.
Frequently Asked Questions
Does Wazuh detect threats in real time or in batches?
Wazuh detects in real time. The manager evaluates each decoded event against the ruleset at ingestion in the analysisd daemon, before the event is indexed. It does not rely on scheduled batch queries against stored data, which is why a matching event can produce an alert within seconds.
How fast does a Wazuh alert appear after an event happens?
On a healthy, well-sized deployment, end-to-end latency from the event on an endpoint to a queryable alert in the indexer is typically one to five seconds. The alert is written to alerts.json slightly sooner, and Active Response can act even faster because it does not wait on indexing.
What causes slow alerts in Wazuh?
Almost always queueing and buffering, not rule complexity. A saturated analysisd event queue (consistently above 90 percent) or a throttling agent buffer adds latency and risks dropped events. Network constraints to a central manager also force more aggressive batching at remote sites.
Can Wazuh block an attack automatically?
Yes, through Active Response. When a chosen rule fires, Wazuh can run a command on the agent or manager to block an IP, disable an account, kill a process or quarantine a file, all within the same second as detection. It should be scoped to high-confidence rules and paired with an allowlist for critical systems.
How do I reduce Wazuh detection latency?
Increase analysisd rule-matching threads on a multi-core manager, drop high-volume low-value events early at the agent so the queue stays empty, and tune the agent buffer for security-critical servers. For geographically spread estates, place collectors or worker nodes closer to the agents to shorten the network hop.
Can Codesecure manage real-time detection for us?
Yes. Codesecure operates Wazuh as a managed SOC with detection latency tracked as a service metric. Our SOC engineers tune thread counts, buffers and collector placement, and build Active Response playbooks scoped to high-confidence detections so threats are contained as they happen.
Get Real-Time Detection That Actually Fires In Seconds
Codesecure deploys and operates Wazuh with detection latency tuned and measured, plus Active Response playbooks that contain attacks as they happen. ISO/IEC 27001:2022 certified delivery, named OSCP and CISSP SOC engineers, fixed monthly retainer.
