Wazuh 4.14.1 – Alerts Not Appearing in Dashboard Despite Successful Agent Connectivity

[Jack Martin]

Dear Wazuh Support Team,

I am facing an issue with my Wazuh environment running Wazuh version 4.14.1.

No security alerts are appearing in the Wazuh Dashboard. However, the agents appear to be functioning correctly, and their connection and disconnection status is working as expected.

I have also verified that the Wazuh Manager and Wazuh Indexer services are running properly. Despite this, alerts/events are not appearing in the Dashboard.

Could you please help me identify where the issue might be and advise what I should check?

In particular, I would appreciate your guidance on checking:

Wazuh Manager alert generation

Agent event collection and forwarding

Wazuh Manager configuration and rules

Wazuh Indexer ingestion and indexing

Wazuh Dashboard data views/index patterns

Alert and rule configuration

Manager, Indexer, and Dashboard logs for any errors

Any known issues specific to Wazuh 4.14.1

Please let me know which logs, configuration files, or command outputs you require from my side. I can provide the necessary information for further troubleshooting.

Thank you for your assistance.

Best regards,

Jack 

[Olamilekan Abdullateef Ajani]

Hello,

The agent connection status confirms they are checking in, but we still need to find out whether events are becoming alerts and reaching the dashboard.

Could you first check whether /var/ossec/logs/alerts/alerts.json is receiving new alerts while an event you expect to alert occurs? If the file isn’t updating, we’ll look at the agent’s log collection settings, the manager’s /var/ossec/logs/ossec.log, and the alert settings in /var/ossec/etc/ossec.conf.

If alerts.json is updating, please run systemctl status filebeat and filebeat test output on that manager, and check cat /var/log/filebeat/ for errors. Then, in Indexer management > Dev Tools, run GET /_cat/indices/wazuh-alerts-*?v to see whether recent alert indices contain documents. If Filebeat reports indexing errors, we can then check the indexer logs and disk space next.

Lastly, You can check the archives in case the events are not matching any alert. Enable it by editing the /var/ossec/etc/ossec.conf file.
<ossec_config>
  <global>
    ----  
    <logall>yes</logall>
    <logall_json>yes</logall_json>
   
 
Then restart the Wazuh-manager.
systemctl restart wazuh-manager

cat /var/ossec/logs/archives/archives.json | grep "part of your log"
Verify that you have the logs, then disable archiving by setting the values to no.

Please let me know what you find.

[Jack Martin]

Dear Wazuh Support Team,

Thank you for your previous guidance regarding our Wazuh troubleshooting.

I would like to clarify a question regarding the Wazuh Indexer in our on-premises deployment.

Currently, our Wazuh environment is creating approximately 3 indices per day, and we would like to understand whether there is any limitation on the total number of indices that can be maintained by the Wazuh Indexer.

Specifically, if the Indexer reaches approximately 1,000 indices, could you please clarify:

Is there any default or recommended maximum number of indices that the Wazuh Indexer can maintain?

If approximately 1,000 indices already exist and new indices continue to be created, what happens to the older indices?

Does Wazuh automatically delete or rotate older indices when a certain index limit or retention policy is reached?

Could reaching a large number of indices affect the visibility or searchability of logs and alerts in the Wazuh Dashboard?

If the environment creates approximately 3 indices per day, what index-retention strategy would you recommend for an on-premises deployment?

Is there a specific Indexer configuration or Index State Management (ISM) policy that we should check to determine whether older indices are being deleted or retained?

We are trying to determine whether our current index creation and retention behavior could be related to the issue where older logs or alerts are not visible in the Wazuh Dashboard.

Please let us know which Indexer commands or configuration details you would like us to provide for further investigation.

Thank you for your assistance.

Best regards,

Jack

On Thu, 17 Sept 2026, 12:33 pm Nguyen Xuan Dong, <dongn...@gmail.com> wrote:

The ladder above covers the pipeline end to end. There's one fork inside it worth naming before you spend a day on the wrong half, Jack.

At the archives step the result splits two ways that look identical from the dashboard. If archives.json fills while alerts.json stays empty, nothing's broken: the events arrived and the default ruleset didn't have anything to match them with. If archives.json is empty too, then the trouble sits upstream and the earlier steps are where it lives.

I measured that first half rather than assumed it. Replaying 24 ATT&CK techniques against a default-config Wazuh install in September 2026, 3 raised an alert, and the discovery, collection, exfiltration and C2 chains raised none at all. So an empty dashboard on a healthy install isn't a surprising outcome, it's the common one. The technique list and the replay harness are public: https://github.com/xuxu298/siem-replay-24-techniques

When you run the archives step, are the events you expected sitting in there, and which technique were you expecting to alert on?

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/37936b16-81b8-4caa-bd6d-b0fc0baf3d45n%40googlegroups.com.

[Olamilekan Abdullateef Ajani]

Hello Jack,

There is no fixed Wazuh limit of 1,000 indices. The number 1,000 refers to the open shard limit per data node, not the number of indices. Each index can contain several primary and replica shards, so the shard count is more important than the index count.

If the shard limit is reached, the Wazuh Indexer does not automatically remove the oldest indices. Instead, requests to create new indices or shards are rejected. This could result in new alerts appearing in alerts.json but not in the Dashboard. Existing indices should remain searchable unless they were deleted by an ISM policy, closed, or have unassigned shards.

Likewise, Wazuh does not delete alert indices simply because a particular index count is reached. Automatic deletion only occurs when an applicable Index State Management policy has been configured.
You can find documentation about this here:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.html

Please run the following in Indexer Management > Dev Tools:

GET /_cluster/health?pretty

GET /_cluster/stats?human

GET /_cat/indices/wazuh-*?v&s=index

GET /_cluster/settings?include_defaults=true&flat_settings=true

GET /_plugins/_ism/policies

GET /_plugins/_ism/explain/wazuh-alerts-*?show_policy=true


Please also share the exact names of the three indices being created each day. The alert indices are date-based, such as wazuh-alerts-4.x-YYYY.MM.DD, but other index types may have different schedules.
Ref:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-indices.html

Finally, please confirm whether /var/ossec/logs/alerts/alerts.json is currently receiving new alerts. This will give an informed decision on whether the original issue is alert generation or indexer ingestion.