What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A valid <if_sid> reference does not guarantee that a Wazuh child rule will match—or that a visible alert will appear. It only makes the child eligible to be evaluated after the referenced parent rule has matched the event. The child’s own conditions, its effective alert level, suppression settings, and the manager’s alert threshold can all explain a silent rule.
The title’s claim that all 4,052 if_sid anchors resolve is not verified against a pinned Wazuh ruleset release or commit, so treat that number as an assertion rather than an independently confirmed count. Either way, a resolvable reference does not prove that the parent matches your event.
As an Amazon Associate I earn from qualifying purchases.
What <if_sid> proves—and what it does not
Wazuh defines <if_sid> as a requirement that a specified rule ID must have matched previously for the child rule to be considered. It is a dependency, not a guarantee that the child will fire. The child still has to meet every other condition in its definition, such as a required message string or decoded-field value. See Wazuh’s rule syntax documentation.
That distinction helps separate two different problems: whether the parent matches the event, and whether the child’s additional conditions match the same event. A reference can exist in the ruleset and still be irrelevant to a particular log if the parent does not match it.
#1 Best Overall
How <if_sid> differs from <if_matched_sid>
These conditions serve different purposes. <if_sid> depends on a rule match for the event being evaluated. <if_matched_sid> is used for correlation over a time period: it looks for an alert from a specified rule within that period and is paired with frequency and timeframe. Wazuh’s rule syntax examples illustrate the time-window form.
| Condition | What it checks | Typical use |
|---|---|---|
<if_sid> |
Whether the specified rule matched previously for the event | Require a parent rule match before evaluating child conditions |
<if_matched_sid> |
Whether an alert for the specified rule occurred within a time period | Correlate repeated matches using frequency and timeframe |
Trace the event with wazuh-logtest
Use the exact log line that should trigger the rule. Wazuh recommends /var/ossec/bin/wazuh-logtest for testing rules; its output helps show which rule matched and where evaluation stopped. See the custom rules documentation.
Rank #2
- Run
/var/ossec/bin/wazuh-logteston the Wazuh manager. - Paste the exact event text as received by Wazuh, rather than a reformatted or abbreviated version.
- Inspect the decoded fields and the rule-matching result. Confirm whether the expected parent rule ID matched.
- If the parent matched, compare the child rule’s conditions with the event’s actual message and decoded values. If it did not, investigate why the parent’s criteria do not fit this event.
- After identifying the matching rule, check its effective level and alert controls before looking for the alert in its destination.
Check whether a match is suppressed or below the alert threshold
Rule matching, alert creation, forwarding, and dashboard visibility are separate stages. Wazuh documents a default manager alert threshold of level 3 or higher; the threshold can be configured. A rule may therefore match without producing an alert at the configured threshold. Check the deployed manager’s setting in the alert-management documentation.
- Level 0: Wazuh classifies level 0 rules as ignored and not shown in the security event dashboard. See Wazuh rule classification.
noalert=1: This setting suppresses an alert while allowing analysis to continue, as described in the rule syntax reference.- Manager threshold: Compare the effective rule level with the threshold configured on the deployed manager; the documented default is not proof that your manager still uses it.
If the rule matched in logtest but the alert is absent from the expected view, continue checking the alert threshold, rule level, suppression behavior, and the intended destination. Do not treat a missing dashboard entry alone as proof that rule matching failed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify the effective rule when using an overwrite
Wazuh warns that overwrite rules do not replace the if_sid, if_group, if_level, if_matched_sid, or if_matched_group labels. If you changed a rule through an overwrite, verify the effective dependency rather than assuming the overwrite changed it. The caveat appears in Wazuh’s custom rules guidance.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
