Dear Wazuh Support Team,
Our Wazuh deployment (version 4.8.1, single-node setup) has stopped displaying alerts in the dashboard. The last alert was received on September 17th at 01:00 AM. Since then, no new alerts have appeared.
Troubleshooting steps already taken:
Restarted Wazuh indexer, dashboard, and manager services.
Verified that no installation or configuration changes were made before or after the issue started.
It seems that the Wazuh API cannot connect properly and wazuh-remoted is stopped.
Could you please advise on how we can bring the services back to a healthy state and restore alert visibility in the dashboard?
I have attached a diagnostic file with environment details for further reference
The error message you are seeing confirms that the wazuh-remoted daemon on node node01 has stopped. This prevents the Wazuh API from connecting and results in the “No API available to connect” error. Since wazuh-remoted handles all agent-based log collection, its stopped state explains why alerts from agents have not appeared in the dashboard since September 17th.
To troubleshoot please run the following checks and share the outputs
Verify wazuh-remoted status: /var/ossec/bin/wazuh-control status | grep remoted
Confirm if the process is running: ps aux | grep wazuh
Check system resources for constraints:
free -h
df -h
refer to https://documentation.wazuh.com/current/installation-guide/wazuh-server/index.html#hardware-requirements
Inspect Wazuh logs for related errors or warnings:
cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"
cat /var/ossec/logs/api.log | grep -i -E "error|warn"
If possible, also share the output of:
GET /manager/daemons/stats?daemons_list=wazuh-remoted
or share the following file output of following file:
/var/ossec/var/run/wazuh-remoted.state
Looking forward to your reply
Hi Stuti,
Thank you for your guidance.
I have restarted the Wazuh manager, dashboard, and indexer services. The connection to the API is now working correctly. However, the dashboard is still not showing or receiving any alerts from the agents.
As requested, please see the attached file containing the outputs and logs for your review.
Looking forward to your advice on next steps to restore alert visibility.





Your issue with the remoted module has been resolved, but you are still not seeing any alerts. This could now be related to the **indexer**, since Filebeat is working correctly.
You can check the indexer cluster logs for errors or warnings with:
cat /var/log/wazuh-indexer/wazuh-cluster.log | grep -i -E "error|warn"
For example, you may see messages about low disk.watermark, which indicate storage problems. If that’s the case, you need to either add more storage or delete old indices to free up space.
From the cluster health you shared earlier, you already have 930 shards in use, which is close to the 1000-shard limit. It also looks like you’re running with only one indexer node and no unassigned shards.
Recommendations
1. Delete old indices
Use the API or CLI to delete older `wazuh-alerts` indices:
DELETE <index_name>
Or via cURL:
curl -k -u admin:<Indexer_Password> -XDELETE "https://<WAZUH_INDEXER_IP>:9200/wazuh-alerts-4.x-YYYY.MM.DD"
2. Add new indexer nodes**
Scaling out will help distribute shards and avoid hitting limits.
Documentation: https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/add-wazuh-indexer-nodes.html)
Please share the cluster logs to know the root cause
In the logs you shared, we can see the following warning:
[WARN ][o.o.m.j.JvmGcMonitorService] [node-1] [gc][young][72555][1383] duration [5s], collections [1]/[5.5s], total [5s]/[1.9m], memory [2.8gb]->[2.2gb]/[3.8gb]This indicates high JVM Garbage Collector (GC) overhead, which is why the Wazuh indexer is struggling and you are not seeing alerts in the Wazuh dashboard.
Your system has around 11 GB of free memory, but the JVM heap is limited to only 3.8 GB, so it cannot use all available RAM.
To fix this, edit /etc/wazuh-indexer/jvm.options and increase the heap size. The recommended value is about half of system RAM (but not more than 31 GB). For a system with ~11 GB RAM, set:
-Xms6gAfter making the change, restart the services:
systemctl daemon-reloadRefer to https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-tuning.html
There is another warning:
[WARN ][o.o.c.r.a.DiskThresholdMonitor] [node-1] Putting index create block on cluster as all nodes are breaching high disk watermark.This means the node’s data path is above the high disk watermark, so the cluster has blocked new index/shard creation.
To resolve this, delete old indices or add more storage.
Delete old indices using the API or cURL:
DELETE <index_name>Another option is to add new indexer nodes to distribute shards and avoid hitting disk limits. Documentation: https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/add-wazuh-indexer-nodes.html
I have updated the JVM settings to -Xms6g/-Xmx6g as recommended and also freed up disk space on the storage. However, I am now facing a login issue from the API. Please find the attached file for more details.
Could you kindly review and advise on the next steps?
To conclude the issue so far, it started when wazuh-remoted stopped, which caused agents to stop sending events, and the dashboard to show no alerts. Restarting services brought the API back, but events still didn’t flow, likely because the indexer was already under memory pressure.
Logs showed GC overhead and disk high-watermark warnings. Even after increasing the heap to 6 GB and freeing disk space, the underlying problem remained: the node has only around 11 GB of total RAM for all Wazuh components — manager, dashboard, and indexer combined. This is why you are still seeing heap errors.
I believe this is due to resource limitations, processes fail: the indexer struggles first (GC pauses), then wazuh-remoted can’t push logs, and eventually wazuh-db crashes because it cannot handle the backlog. This leads to the API going down and alerts not appearing. The cluster previously reached 930 shards, which is another warning sign. Even if there are no unassigned shards now, almost hitting the shard limit stresses the cluster heavily. In short, this is fundamentally a resource and sizing issue.
To resolve this issue, you can consider the following
1. For production, a single node with 11 GB RAM is insufficient. You can refer to the Wazuh hardware requirements.
Either you can upgrade the node’s RAM or split components across multiple nodes (dedicated manager, indexer, and dashboard). The exact resources required depend on the EPS and the number of agents.