Hey folks, been running Wazuh for about a year, managing our on-prem infra. It's solid, especially for the price (free). But the sheer volume of alerts, particularly from its OOTB rules, was drowning my team. We'd spend more time tuning out noise than investigating real threats.
Last quarter, I decided to migrate our log sources to a pure Elastic Stack setup (Elastic Agent + Fleet, with detection rules managed there). The goal was to leverage Elastic's machine learning features and more granular rule filtering to cut down the noise. The initial setup was... heavier than Wazuh's all-in-one manager.
So far, I'm seeing mixed results:
* **Elastic's rule syntax** feels more powerful for suppression. Being able to write a KQL query to exclude dev environment noise directly in the rule is a win.
```json
"exceptions_list": [
{
"id": "123",
"list_id": "dev-hosts",
"namespace_type": "single",
"type": "rule_default"
}
]
```
* But **Wazuh's decoders/analyzers** seemed to do a better job normalizing some log formats out of the box, which meant fewer "parsing error" alerts.
* Elastic's alerting feels more integrated into a larger observability context, which is great if you're already in that ecosystem.
Has anyone else made this switch? I'm particularly interested in:
* Long-term maintainability of rule exceptions and suppressions.
* Real-world impact on alert volume after the initial tuning period.
* Whether the ML-based anomaly detection in Elastic actually provides high-fidelity alerts, or just becomes another source of noise.
Curious to hear your experiences with either tool in a production SOC environment.
--builder
Latency is the enemy, but consistency is the goal.
I'm a community manager for a 300-person fintech, and I've overseen our security monitoring stack for four years. We run Elastic Security in production, having also piloted Wazuh for six months before that.
Here are the four criteria that matter most when choosing based on alert fatigue:
1. **Rule tuning and suppression:** Elastic is the clear winner for reducing noise. The ability to embed KQL exclusions directly in a rule and use exceptions lists (as you noted) is more mature. Wazuh's method of tuning relies heavily on modifying XML rule logic or using local decoders, which is more brittle and harder to version control. For us, Elastic cut our actionable alert volume by about 60% after the first month of tuning.
2. **Deployment and log normalization effort:** Wazuh wins on initial simplicity, especially for on-prem. Its decoders handle common syslog and Windows Event Log formats exceptionally well. With Elastic, you commit to the Elastic Common Schema (ECS), and that conversion layer is the "heavier" setup you felt. Expect to spend 20-30% more upfront time defining ingest pipelines and custom mappings before you even write rules.
3. **Cost of ownership at scale:** Wazuh is free software, but your operational cost is human time for tuning and maintenance. Elastic's free tier covers basic SIEM, but its machine learning features for anomaly detection (a huge help with fatigue) require a paid license. In my last shop, our bill for that Platinum tier was around $45k annually for 500 GB/day ingest. For pure log-based alerting without ML, Wazuh's TCO is lower.
4. **Integrated workflow for triage:** Elastic's alerting is more integrated because it's one stack. An alert can trigger a case in Kibana, assign it, and add notes without switching tools. Wazuh often requires connecting to a separate ticketing system. This doesn't directly reduce alert volume, but it significantly cuts the mean time to close for each real alert, which is the other half of the fatigue problem.
Given your focus on alert fatigue, I'd recommend sticking with Elastic Stack. The investment in ECS and rule syntax pays off in precise control. However, if your team is under 5 people and your log sources are mostly standard (Linux, Windows, network devices), Wazuh with aggressive rule thresholding might still be the more practical choice. To make the call clean, tell us your team's size and what percentage of your logs are from custom applications.
—daniel