Urgent Help required!

[Shreya Chakrabarty]

Hi team!

I am facing a rather unusual issue with my wazuh server. I have been facing multiple internal server error issues, credential issues (when i enter it the first time it shows invalid the first time and when i refresh it the credentials are suddenly valid!) I am attaching the screenshots that I have been encountering since few days. Please help me out. 

[Olamilekan Abdullateef Ajani]

Hello,

Thanks for the screenshots. Based off that, there seem to be two related issues here rather than just an incorrect admin password.

The "Error getting the authorization token" indicates that the dashboard is having trouble authenticating to the Wazuh server API on port 55000. The other internal/search errors could also involve communication with the Wazuh indexer, so based on this, we should probably first check the health of all three components.

Could you please share the output of:

systemctl status wazuh-indexer wazuh-manager wazuh-dashboard --no-pager

free -h
df -h

grep -i -E "error|warn|circuit|memory|watermark" /var/log/wazuh-indexer/wazuh-cluster.log | tail -50

grep -i -E "error|warn" /var/ossec/logs/ossec.log | tail -50

journalctl -u wazuh-dashboard --since "1 hour ago" | grep -i -E "error|warn" | tail -100

Please run these around the time the issue occurs if possible.

For the indexer:

curl -k -u admin:<INDEXER_PASSWORD> https://127.0.0.1:9200/_cluster/health?pretty

And for the Wazuh server API:

curl -k -u wazuh-wui:<WAZUH_WUI_PASSWORD> -X POST "https://127.0.0.1:55000/security/user/authenticate?raw=true"

Please also check the API configuration used by the dashboard for accuracy and completeness: cat /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

Verify the url, port, username and password for wazuh-wui. If the wazuh-wui password was changed on the manager but not updated here, the dashboard will fail to obtain an authorization token.

As a quick test, you can also try an incognito window, but if the errors continue then we review the logs.

Lastly, could you confirm whether this is an all-in-one or distributed installation, the amount of RAM/CPU allocated, number of agents, and the installed version of the Wazuh instance.
Ref: https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/troubleshooting.html

I await feedback from you.

[Lakshmikanth P]

This is probably an update related issue I faced the same thing when I didn’t update wazuh to latest version

On Wed, 26 Aug 2026 at 8:03 PM, Shreya Chakrabarty <shreya....@gmail.com> wrote:

Hi team!

I am facing a rather unusual issue with my wazuh server. I have been facing multiple internal server error issues, credential issues (when i enter it the first time it shows invalid the first time and when i refresh it the credentials are suddenly valid!) I am attaching the screenshots that I have been encountering since few days. Please help me out. 

--
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/ba9d62e4-b1a6-479f-96ee-836a816489f9n%40googlegroups.com.

[Shreya Chakrabarty]

That's the thing! this is happening AFTER i updated Wazuh.

[Shreya Chakrabarty]

Hi! 

I have added the screenshots in a google drive since I was not able to post all the screenshots at one go. Unfortunately, the problem persisted even in incognito mode. Furthermore, i successfully ran  curl -k -u wazuh-wui:<WAZUH_WUI_PASSWORD> -X POST "https://127.0.0.1:55000/security/user/authenticate?raw=true"
Please let me know if any other screenshots are needed. I am also attaching additional screenshots (named: update api credentials, wazuh signin of the issue that i am continuing to face even after running all these commands. 

Link: https://drive.google.com/drive/folders/19_4iG6h6uMOnVyz95Po2VI_eHIe5Bc4B?usp=sharing

[Olamilekan Abdullateef Ajani]

Hello Shreya,

Thanks for the outputs. This is a much clearer explanation for the behavior you have been seeing.

The main issue is the Wazuh indexer hitting its JVM parent circuit breaker:

circuit_breaking_exception
[parent] Data too large
limit: 972.7mb
real usage: ~1GB
statusCode: 429
Too Many Requests

The same error is also appearing during dashboard authentication:

Failed authentication: Error: [circuit_breaking_exception]

That explains why the dashboard can report "Invalid username or password" and then accept exactly the same credentials after a refresh. In those cases the authentication request is being rejected because the indexer is under JVM heap pressure, rather than because the password is necessarily wrong.

It also explains the "Too Many Requests", search errors, and other intermittent internal server errors shown in the dashboard.

Your disk usage looks healthy at only 18%, and the host still has a good amount of available physical RAM, so disk watermarks or overall system memory exhaustion do not appear to be the immediate problem.

The circuit-breaker limit in your log is 972.7 MB. which sets its parent breaker to 95% of the JVM heap, and this suggests the indexer is currently running with approximately a 1 GiB heap. We can try to confirm this with the below query:

sudo grep -E '^-Xm[sx]' /etc/wazuh-indexer/jvm.options

ps -ef | grep '[w]azuh-indexer' | grep -Eo 'Xm[sx][0-9]+[mg]'

Also check whether there are any additional JVM overrides: ls -l /etc/wazuh-indexer/jvm.options.d/ 2>/dev/null

If it confirms:
-Xms1g
-Xmx1g

Please increase to:
-Xms4g
-Xmx4g

The recommendation is that Xms and Xmx are set to the same value, and that should be half of the system RAM for a dedicated indexer. Since this machine also runs the manager and dashboard, starting with 4 GiB gives the indexer significantly more headroom while still leaving memory for the other components.

Back up the file first:

sudo cp /etc/wazuh-indexer/jvm.options /etc/wazuh-indexer/jvm.options.bak

Then update the values and restart: sudo systemctl restart wazuh-indexer

After the restart, confirm the new heap: ps -ef | grep '[w]azuh-indexer' | grep -Eo 'Xm[sx][0-9]+[mg]'

Then monitor for any new breaker errors:

sudo journalctl -u wazuh-indexer --since "10 minutes ago" | grep -i -E "circuit|breaker|data too large|error|warn"

Your test against 127.0.0.1:9200 being refused does not indicate another indexer problem. The service is running, and the dashboard is receiving responses from it, so it may simply be listening on the server's configured IP rather than loopback.

Please check:

grep -E '^[[:space:]]*network.host' /etc/wazuh-indexer/opensearch.yml

sudo ss -lntp | grep ':9200'

Then repeat the health test against the address on which it is actually listening:

curl -k -u admin https://<INDEXER_IP>:9200/_cluster/health?pretty

Once the indexer is stable, please retry the dashboard and API health checks. If the API connection on port 55000 still fails after the circuit-breaker errors have stopped, please let me know.

One other thing, the screenshot you shared contains the admin password in the curl command. I recommend changing that password and avoiding sharing passwords.

Please share the Xms/Xmx output and let me know whether the circuit-breaker messages stop after increasing the heap.

[Shreya Chakrabarty]

It worked! thank you so much! 

Now I am confused about one more thing. When I sign in, i can't see any critical alerts. Why? There are critical alerts visible given any day. Also attaching the screenshot for curl -k -u admin https://<INDEXER_IP>:9200/_cluster/health?pretty.

[Olamilekan Abdullateef Ajani]

Hello Shreya,

I am glad the previous issue is resolved.

Regarding the 0 Critical alerts, the Overview page is only counting alerts generated during the last 24 hours. And the alert panels are classified as

Critical: rule.level >= 15
High:     rule.level 12–14
Medium:   rule.level 7–11
Low:      rule.level 0–6

So if the critical alerts you are seeing elsewhere occurred outside the last 24 hours, it means the 0 shown is expected.

To confirm, go to Threat Hunting > Events, set the time range to Last 24 hours, and filter for alerts where:

rule.level >= 15

If that also returns 0, then the Overview page is accurate.

Regarding the indexer health output, it looks better now:

The yellow means all primary shards are allocated but one or more replica shards are not allocated. Since this is a single-node indexer, that can occur because a replica cannot be placed on the same node as its primary.

You can confirm the four unassigned shards are replicas with:

curl -k -u admin "https://192.168.1.34:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason" | grep UNASSIGNED

If the prirep column shows r, they are replicas.

Regards,