Wazuh Alerting: Telegram notifications stopped after deduplication attempt

38 views
Skip to first unread message

Mohammad Firman Riyadi

unread,
Feb 7, 2026, 1:57:17 AM (5 days ago) Feb 7
to Wazuh | Mailing List
After I applied deduplication settings in the Wazuh Dashboard Alerting menu and modified my local rules to fix duplicate Telegram notifications, all alerts stopped triggering entirely; could anyone help me troubleshoot why notifications are no longer being sent?

hasitha.u...@wazuh.com

unread,
Feb 7, 2026, 3:01:02 AM (5 days ago) Feb 7
to Wazuh | Mailing List
Hi Firman,

To help diagnose and resolve this, please provide the following information:

1. Custom Rule Details

  • Please share the custom rule(s) you modified to address the duplicate alerts
  • Include the complete rule configuration (from your local_rules.xml or custom rules file)

2. Alert Verification

After implementing your custom rule fixes, please check:

a) Log File Verification:

  • Check if the alerts are being written to /var/ossec/logs/alerts/alerts.json
  • Run: tail -f /var/ossec/logs/alerts/alerts.json and share relevant entries

b) Dashboard Status:

  • Are the duplicate alerts still appearing on the Wazuh dashboard?
  • If yes, please share a screenshot showing the duplicates.

3. Dashboard Alerting Configuration

If alerts are showing correctly on the dashboard but you're experiencing issues with notifications:

  • This indicates the Wazuh manager is functioning properly
  • The issue may be in the dashboard alerting configuration
  • Please share:
    • Your alerting configuration details
    • Any monitors or alert definitions you've created or modified
    • Trigger conditions and actions configured

4. Telegram Integration Test

  • Verify if test messages are being successfully sent to Telegram.

Please provide updates on each of these points so we can identify the root cause.

Mohammad Firman Riyadi

unread,
Feb 9, 2026, 1:44:05 AM (3 days ago) Feb 9
to Wazuh | Mailing List

I created a custom rule to deduplicate web server 400 errors (Rule 31151). My goal is to receive only one alert per hour if the source IP and location are the same.

XML
<group name="custom_dedup"> <rule id="100151" level="10" frequency="1" timeframe="3600"> <if_matched_sid>31151</if_matched_sid> <same_source_ip /> <same_location /> <description>Multiple web server 400 errors (DEDUPLICATED - 1 alert per hour)</description> <mitre> <id>T1595.002</id> </mitre> </rule> </group>
2. The Alerting Query (Deduplication Attempt)

This is the query I am using in the alerting menu specifically for these deduplicated IDs:

JSON
{ "size": 10, "query": { "bool": { "must": [ { "range": { "timestamp": { "from": "now-24h", "to": null, "include_lower": true, "include_upper": true, "time_zone": "+07:00" } } }, { "terms": { "rule.id": ["100151", "100571", "101131"] } } ] } }, "sort": [ { "timestamp": { "order": "desc" } } ] }
3. The General Alerting Query

When I use the following query to capture all high-level alerts (Level 10 and above) for Telegram notifications, I still see duplicate alerts for the rules that should be deduplicated:

JSON
{ "size": 10, "query": { "bool": { "must": [ { "range": { "timestamp": { "from": "now-24h", "to": null, "include_lower": true, "include_upper": true, "time_zone": "+07:00" } } }, { "range": { "rule.level": { "from": 10, "to": null, "include_lower": true, "include_upper": true } } } ] } }, "sort": [ { "timestamp": { "order": "desc" } } ] }

The Problem: Even though rule 100151 is active, the original alerts and the new deduplicated alerts seem to both trigger or show up in the results, leading to duplicate notifications in Telegram.

How can I properly suppress the original alert so that only the deduplicated rule triggers the notification? Should I be using dependent_level or a different if_matched_sid logic to ensure the base rule doesn't fire alongside the custom one?

Any help would be greatly appreciated!


Mohammad Firman Riyadi

unread,
Feb 9, 2026, 1:44:09 AM (3 days ago) Feb 9
to Wazuh | Mailing List

I created a custom rule to deduplicate web server 400 errors (Rule 31151). My goal is to receive only one alert per hour if the source IP and location are the same.

XML
<group name="custom_dedup"> <rule id="100151" level="10" frequency="1" timeframe="3600"> <if_matched_sid>31151</if_matched_sid> <same_source_ip /> <same_location /> <description>Multiple web server 400 errors (DEDUPLICATED - 1 alert per hour)</description> <mitre> <id>T1595.002</id> </mitre> </rule> </group>
2. The Alerting Query (Deduplication Attempt)

This is the query I am using in the alerting menu specifically for these deduplicated IDs:

JSON
{ "size": 10, "query": { "bool": { "must": [ { "range": { "timestamp": { "from": "now-24h", "to": null, "include_lower": true, "include_upper": true, "time_zone": "+07:00" } } }, { "terms": { "rule.id": ["100151", "100571", "101131"] } } ] } }, "sort": [ { "timestamp": { "order": "desc" } } ] }
3. The General Alerting Query

When I use the following query to capture all high-level alerts (Level 10 and above) for Telegram notifications, I still see duplicate alerts for the rules that should be deduplicated:

JSON
{ "size": 10, "query": { "bool": { "must": [ { "range": { "timestamp": { "from": "now-24h", "to": null, "include_lower": true, "include_upper": true, "time_zone": "+07:00" } } }, { "range": { "rule.level": { "from": 10, "to": null, "include_lower": true, "include_upper": true } } } ] } }, "sort": [ { "timestamp": { "order": "desc" } } ] }

The Problem: Even though rule 100151 is active, the original alerts and the new deduplicated alerts seem to both trigger or show up in the results, leading to duplicate notifications in Telegram.

How can I properly suppress the original alert so that only the deduplicated rule triggers the notification? Should I be using dependent_level or a different if_matched_sid logic to ensure the base rule doesn't fire alongside the custom one?

Any help would be greatly appreciated!





Pada Sabtu, 07 Februari 2026 pukul 15.01.02 UTC+7 hasitha.u...@wazuh.com menulis:

hasitha.u...@wazuh.com

unread,
Feb 10, 2026, 12:01:32 AM (2 days ago) Feb 10
to Wazuh | Mailing List
Hi Mohammad,

Instead of adding a new custom rule, I suggest overwriting the existing rule to avoid duplicate alerts based on your scenario
Ref: https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html#changing-existing-rules

For example, you can copy rule 31151 into the custom rules file and remove rule 100151 from that file. Then, add the overwrite="yes" attribute to the rule tag. This will allow you to overwrite the existing rule and adjust it according to your requirements.

  1. <group name="web,accesslog,">
  2.  
  3.   <rule id="31151" level="10" frequency="14" timeframe="3600" overwrite="yes">
  4.     <if_matched_sid>31101</if_matched_sid>
  5.     <same_source_ip />
  6.     <same_location />
  7.     <description>Multiple web server 400 error codes from source IP and location.</description>
  1.     <mitre>
  2.       <id>T1595.002</id>
  3.     </mitre>
  1.     <group>web_scan,recon,pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11,nist_800_53_SI.4,tsc_CC6.6,tsc_CC7.1,tsc_CC8.1,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  2.   </rule>
  3.  
  4. </group>

I believe you don’t need both alerts. Using this approach will help you easily mitigate the duplicate alert issue

Additionally, if you want this alert to trigger only once per hour, you can use the ignore option in the rule tag to define a time period during which further alerts will not be triggered. You can find more details here.
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#rule

Please let me know if you have any updates or questions on this.
Reply all
Reply to author
Forward
0 new messages