A Wazuh alternative for small teams: security monitoring without the second job
Wazuh is a capable open-source SIEM - and a demanding one. If you're a small team eyeing the indexer requirements, the rule tuning, and the maintenance surface, here's an honest comparison and a lighter path to Linux threat detection.
The AlertKick team
Wazuh deserves its reputation. It’s genuinely open source, covers an enormous surface - log analysis, FIM, vulnerability detection, compliance modules, agents for every OS - and for organisations with a security engineer to feed it, it’s one of the best deals in the industry. If that’s you, close this tab with our blessing.
This post is for the other readers: the two-to-ten-person teams who spun up Wazuh because it was the serious free option, and six weeks later are maintaining a security platform instead of shipping their product.
Where the effort actually goes
The pattern repeats consistently enough to be predictable:
The stack under the stack. Wazuh isn’t an agent - it’s an architecture: manager, indexer (an OpenSearch-based store), and dashboard, each with its own care and feeding. The recommended starting hardware for the central components is a server bigger than many of the fleets it monitors, and index storage grows with every log line. Small teams end up running a dedicated - often their largest - box just to watch the others.
Default rules are written for someone else. Out of the box, thousands of rules produce a firehose in which routine cron jobs, package upgrades, and login events all generate findings. The intended workflow is that you tune: suppress, reclassify, write local rules in XML, iterate. Tuning is real security engineering and someone has to own it - untuned, the dashboard becomes a place nobody looks, which is strictly worse than no dashboard.
Alerting is an integration project. Getting a specific, trustworthy page to a phone - this rule, this severity, this person, escalate if unacknowledged - means wiring integrations and often another tool on top for on-call. The paging layer you assumed was included is homework.
Upgrades are events. Manager, indexer, dashboard, and fleet agents move together; version pinning and release notes become part of someone’s job.
Add it up and the real price of the free SIEM is roughly a part-time role. For a fifty-engineer company with a security function, that’s fine - it’s what the tool is for. For a five-person team, it’s the most expensive kind of free.
The question underneath: SIEM or answers?
A SIEM is a platform for asking arbitrary security questions of your logs. Most small teams don’t have arbitrary questions. They have about five, permanently:
- Did someone log into a server who shouldn’t have?
- Is anything running that shouldn’t be - a miner, a reverse shell, a process out of
/tmp? - Did a file change that matters -
authorized_keys, cron, system binaries? - Is a host talking to a known-bad address?
- Can we show an auditor evidence of all of the above?
If your questions are those five, you don’t need a queryable log platform - you need those five answers, continuously, with a page when one goes bad. That’s a product-shape difference, not a quality difference.
What the lighter path looks like
AlertKick’s answer to that shape: one eBPF agent per host, nothing to host yourself. Kernel-level detections for logins, processes, network, and file integrity are on by default with sensible rules - tuned by people who’ve run production fleets, mapped to MITRE ATT&CK, and fed through AI triage that reads each event in context and explains it in plain English. Threat-intel feeds come wired in. Escalation policies and on-call rotations are part of the platform, so “page the right person, escalate if ignored” is configuration, not integration. Compliance evidence collects itself. And the same agent does the infrastructure monitoring - so it replaces a second stack too, priced per host, not per seat or per gigabyte of index.
What you give up is real and worth naming: there’s no arbitrary-query log lake, no custom XML rule language, no self-hosted-everything control (though an on-prem deployment exists for teams that need it), and Windows coverage is narrower than Wazuh’s today. If those are dealbreakers, Wazuh remains the right tool - staffed properly.
A fair way to decide
Run the experiment both directions. If you’re evaluating: stand up Wazuh in a VM and honestly clock the hours to your first trustworthy, tuned page. Then start an AlertKick trial, install the agent on one host, SSH in, and clock the minutes to the same outcome. Same fleet, same week, compare what reached your phone - and what it cost in attention to get there.
Security monitoring you maintain instead of use protects nobody. Pick the one your team will still be running - and reading - in a year.
