Troubleshooting: Wazuh API Health Check Timeout on Dashboard Login

Problem Statement#

Users experience API health check timeouts when logging into the Wazuh Dashboard and navigating to /app/wz-home. The health check consistently times out on the first connection attempt, requiring page refreshes to successfully connect. Once the initial connection is established, the dashboard works normally—until the next logout/login cycle, when the issue recurs.

Typical User Experience:

Login to Wazuh Dashboard
Navigate to /app/wz-home
Health check times out (20,000ms default timeout)
Refresh page multiple times
Finally connects after 2-3 attempts
Dashboard works normally thereafter
Logout and login → Issue repeats

Severity: Medium (Access delayed but not blocked)

Affected Component: Wazuh Manager API → Dashboard communication

Reported By: Community user @barcle

Symptoms#

Dashboard Behavior#

1
Loading... API Health Check
2
⏱ Request timeout (exceeded 20,000ms)
3
❌ Failed to connect to Wazuh API
4
🔄 Retry required (2-3 times)
5
✅ Eventually connects

Key Observations#

✅ Issue only on first connection after login
✅ Subsequent operations work normally
✅ Dashboard-to-Manager connectivity exists
❌ Initial health check exceeds 20s timeout
❌ Requires multiple page refreshes
🔄 Issue reappears after logout/login cycle

Network Trace#

1
# First attempt
2
POST /api/health-check -> 504 Gateway Timeout (20,000ms)
3

4
# Second attempt (after refresh)
5
POST /api/health-check -> 200 OK (2,300ms)
6

7
# Subsequent requests
8
GET /api/agents -> 200 OK (450ms)
9
GET /api/rules -> 200 OK (320ms)

Root Cause Analysis#

The timeout issue stems from one or more resource constraints:

Primary Causes#

1. High CPU Usage on Wazuh Manager#

Manager overloaded processing agent events
API requests queued behind analysis tasks
First request triggers initialization tasks
CPU throttling under sustained load

2. Disk I/O Bottleneck#

Slow disk causing database queries to lag
Full disk causing write operations to block
Swap usage indicating memory pressure
Log rotation blocking I/O

3. Memory Exhaustion#

Insufficient RAM for API operations
Swap usage causing extreme slowdown
Memory leaks in long-running processes
Insufficient cache for frequently accessed data

4. API Cold Start Delay#

First request after idle period slow
Connection pool initialization
SSL/TLS handshake overhead
Database connection establishment

5. Network Latency/Firewall#

Dashboard-Manager communication delayed
Firewall inspection causing delays
Network congestion or packet loss
Reverse proxy overhead

6. Cluster Synchronization Issues#

Multi-node cluster out of sync
Master node overwhelmed
Worker nodes not distributing load
Split-brain scenario

Diagnostic Steps#

Step 1: Check System Resources#

CPU Usage#

1
# Real-time CPU monitoring
2
top -bn1 | grep "Cpu(s)" | sed "s/.*, \([0-9.]*\)% id.*/\1/" | awk '{print 100 - $1"%"}'
3

4
# Alternative detailed view
5
mpstat 1 5
6

7
# Per-process CPU usage
8
ps aux --sort=-%cpu | head -10
9

10
# Wazuh-specific processes
11
ps aux | grep -E "wazuh|ossec" | grep -v grep

Expected Output (Healthy):

1
CPU Usage: 15-40% (normal load)
2
CPU Usage: 70-100% (problem - overloaded)

Critical Processes to Monitor:

wazuh-analysisd - Log analysis engine
wazuh-remoted - Agent communication
wazuh-apid - API server
wazuh-db - Database operations

Memory Usage#

1
# Memory overview
2
free -m
3

4
# Detailed memory stats
5
vmstat 1 5
6

7
# Check for swap usage
8
swapon --show
9

10
# Memory by process
11
ps aux --sort=-%mem | head -10

Expected Output (Healthy):

1
              total        used        free      shared  buff/cache   available
2
Mem:           7824        3456        2345         123        2023        3890
3
Swap:          2047           0        2047

Warning Signs:

Free memory < 500MB
Swap usage > 0MB
Available memory < 20% of total

Disk Usage#

1
# Disk space
2
df -h
3

4
# I/O statistics
5
iostat -x 1 5
6

7
# Disk usage by directory
8
du -sh /var/ossec/* | sort -h
9

10
# Check specific critical paths
11
df -h /var/ossec/
12
df -h /var/log/

Expected Output:

1
Filesystem      Size  Used Avail Use% Mounted on
2
/dev/sda1       100G   45G   50G  48% /

Critical Thresholds:

Disk usage > 85% - WARNING
Disk usage > 95% - CRITICAL

Step 2: Check Wazuh API Logs#

1
# API access log
2
tail -f /var/ossec/logs/api.log
3

4
# Filter for errors
5
grep -E "ERROR|WARN|timeout|failed" /var/ossec/logs/api.log | tail -50
6

7
# Check for specific health check requests
8
grep "health-check" /var/ossec/logs/api.log | tail -20
9

10
# Analyze response times
11
awk '/health-check/ {print $1, $2, $NF}' /var/ossec/logs/api.log | tail -20

Look For:

1
2025/10/07 10:15:23 ERROR: Request timeout after 20000ms
2
2025/10/07 10:15:24 WARN: High API response time: 18540ms
3
2025/10/07 10:15:25 ERROR: Database connection pool exhausted
4
2025/10/07 10:15:26 WARN: CPU usage above 90%, throttling requests

Step 3: Check Wazuh Manager Logs#

1
# Main manager log
2
tail -f /var/ossec/logs/ossec.log
3

4
# Filter for errors and warnings
5
grep -E "ERROR|WARN|CRITICAL" /var/ossec/logs/ossec.log | tail -50
6

7
# Check for resource warnings
8
grep -E "memory|cpu|disk|resource" /var/ossec/logs/ossec.log | tail -30
9

10
# Analyze startup times
11
grep "started" /var/ossec/logs/ossec.log | tail -20

Step 4: Test API Performance#

Manual Health Check#

1
# Time the health check request
2
time curl -k -X GET "https://localhost:55000/health" \
3
  -H "Authorization: Bearer $TOKEN"
4

5
# Detailed timing breakdown
6
curl -k -X GET "https://localhost:55000/health" \
7
  -H "Authorization: Bearer $TOKEN" \
8
  -w "\nTime Total: %{time_total}s\nTime Connect: %{time_connect}s\nTime StartTransfer: %{time_starttransfer}s\n"

Expected Response Times:

Good: < 2 seconds
Acceptable: 2-5 seconds
Slow: 5-15 seconds
Problematic: > 15 seconds

API Endpoint Testing#

1
# Test multiple endpoints
2
for endpoint in "/cluster/healthcheck" "/agents/summary/status" "/manager/status"; do
3
  echo "Testing $endpoint"
4
  time curl -k -X GET "https://localhost:55000$endpoint" \
5
    -H "Authorization: Bearer $TOKEN" \
6
    -o /dev/null -s
7
  echo ""
8
done

Step 5: Check Cluster Health (Multi-Node Setup)#

1
# Cluster status
2
/var/ossec/bin/cluster_control -l
3

4
# Cluster health via API
5
curl -k -X GET "https://localhost:55000/cluster/healthcheck?pretty" \
6
  -H "Authorization: Bearer $TOKEN"
7

8
# Indexer cluster health
9
curl -k -X GET "https://localhost:9200/_cluster/health?pretty" \
10
  -u admin:admin

Expected Output (Healthy Cluster):

1
{
2
  "status": "green",
3
  "number_of_nodes": 3,
4
  "active_primary_shards": 10,
5
  "active_shards": 20,
6
  "relocating_shards": 0,
7
  "initializing_shards": 0,
8
  "unassigned_shards": 0
9
}

Warning Signs:

Status: “yellow” or “red”
Unassigned shards > 0
Node count mismatch
Initializing shards stuck

Step 6: Check Network Connectivity#

1
# Test latency between Dashboard and Manager
2
ping -c 10 <manager-ip>
3

4
# Trace route
5
traceroute <manager-ip>
6

7
# Test API port connectivity
8
nc -zv <manager-ip> 55000
9

10
# Measure API latency from dashboard server
11
time curl -k -X GET "https://<manager-ip>:55000/health" \
12
  -H "Authorization: Bearer $TOKEN" \
13
  -o /dev/null -s

Step 7: Analyze Dashboard Logs#

1
# On Wazuh Dashboard server
2
tail -f /var/log/wazuh-dashboard/wazuh-dashboard.log
3

4
# Filter for API connection issues
5
grep -E "API|timeout|connection|health" /var/log/wazuh-dashboard/wazuh-dashboard.log | tail -50
6

7
# Check browser console (from user's machine)
8
# Press F12 → Console tab → Look for failed API requests

Solution Steps#

Solution 1: Increase API Timeout (Quick Fix)#

If the API is functional but slightly slow:

1
# Edit Wazuh Dashboard configuration
2
vim /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

Increase timeout value:

1
hosts:
2
  - default:
3
      url: https://localhost
4
      port: 55000
5
      username: wazuh-wui
6
      password: wazuh-wui
7
      run_as: false
8
timeout: 30000  # Increase from 20000ms to 30000ms (30 seconds)

Restart dashboard:

1
systemctl restart wazuh-dashboard

⚠️ Note: This is a workaround, not a root cause fix.

Solution 2: Optimize CPU Usage#

Scale Vertically (Add CPU)#

1
# If running on VM/cloud, increase CPU allocation
2
# AWS: Resize instance type
3
# VMware: Edit VM settings → Add CPUs
4
# Azure: Change VM size
5

6
# Verify after resize
7
nproc  # Should show new CPU count
8
lscpu | grep "CPU(s)"

Optimize Wazuh Configuration#

1
# Edit ossec.conf
2
vim /var/ossec/etc/ossec.conf

Reduce analysis load:

1
<global>
2
  <!-- Reduce logging verbosity -->
3
  <logall>no</logall>
4
  <logall_json>no</logall_json>
5

6
  <!-- Limit queue size -->
7
  <queue_size>16384</queue_size>  <!-- Reduce if CPU-bound -->
8
</global>
9

10
<remote>
11
  <!-- Limit concurrent agent connections -->
12
  <connection>secure</connection>
13
  <queue_size>16384</queue_size>
14
</remote>
15

16
<analysisd>
17
  <!-- Reduce decode threads if single-core -->
18
  <decoder_order_size>256</decoder_order_size>
19
  <log_fw>no</log_fw>
20
</analysisd>

Restart manager:

1
systemctl restart wazuh-manager

Solution 3: Increase Memory Allocation#

Add Swap (Emergency)#

1
# Create 4GB swap file
2
dd if=/dev/zero of=/swapfile bs=1G count=4
3
chmod 600 /swapfile
4
mkswap /swapfile
5
swapon /swapfile
6

7
# Make permanent
8
echo '/swapfile none swap sw 0 0' >> /etc/fstab
9

10
# Verify
11
swapon --show
12
free -m

Scale RAM (Recommended)#

1
# Increase VM memory allocation
2
# Minimum recommendations:
3
# - Small deployment (< 100 agents): 4GB RAM
4
# - Medium deployment (100-1000 agents): 8GB RAM
5
# - Large deployment (> 1000 agents): 16GB+ RAM
6

7
# After resize, verify
8
free -m

Optimize Memory Usage#

1
# Clear system cache (safe operation)
2
sync; echo 3 > /proc/sys/vm/drop_caches
3

4
# Identify memory hogs
5
ps aux --sort=-%mem | head -10
6

7
# Restart memory-intensive services
8
systemctl restart wazuh-indexer  # If memory usage is high

Solution 4: Clean Up Disk Space#

1
# Find large files
2
find /var/ossec -type f -size +100M -exec ls -lh {} \;
3

4
# Clean old logs (older than 30 days)
5
find /var/ossec/logs/archives -name "*.gz" -mtime +30 -delete
6
find /var/ossec/logs/alerts -name "*.gz" -mtime +30 -delete
7

8
# Clean old databases
9
find /var/ossec/queue/db -name "*.db-journal" -mtime +7 -delete
10

11
# Rotate logs manually if needed
12
/var/ossec/bin/wazuh-logrotate
13

14
# Check disk usage after cleanup
15
df -h /var/ossec/

Configure Log Rotation:

1
# Edit logrotate configuration
2
vim /etc/logrotate.d/wazuh

1
/var/ossec/logs/ossec.log {
2
    daily
3
    rotate 7
4
    compress
5
    delaycompress
6
    missingok
7
    notifempty
8
    create 0640 wazuh wazuh
9
}
10

11
/var/ossec/logs/api.log {
12
    daily
13
    rotate 7
14
    compress
15
    delaycompress
16
    missingok
17
    notifempty
18
    create 0640 wazuh wazuh
19
}

Solution 5: Optimize API Performance#

Enable API Connection Pooling#

1
# Edit API configuration
2
vim /var/ossec/api/configuration/api.yaml

Optimize settings:

1
host: 0.0.0.0
2
port: 55000
3

4
# Increase worker processes
5
processes: 4  # Match CPU core count
6

7
# Connection pool settings
8
max_requests: 1000
9
max_requests_jitter: 50
10

11
# Timeout settings
12
timeout: 30
13

14
# Logging
15
logging:
16
  level: info  # Change to 'warning' to reduce overhead
17
  path: /var/ossec/logs/api.log
18
  max_size: 100mb
19
  rotate: 12
20

21
# Cache settings
22
cache:
23
  enabled: true
24
  time: 0.75  # Cache duration in seconds

Restart API:

1
systemctl restart wazuh-manager
2
# Or specifically:
3
/var/ossec/bin/wazuh-apid restart

Enable HTTPS Keep-Alive#

1
# Edit nginx config (if using reverse proxy)
2
vim /etc/nginx/conf.d/wazuh.conf

1
upstream wazuh_api {
2
    server localhost:55000;
3
    keepalive 32;  # Enable connection pooling
4
}
5

6
server {
7
    listen 443 ssl;
8

9
    # Keep-alive settings
10
    keepalive_timeout 65;
11
    keepalive_requests 100;
12

13
    location / {
14
        proxy_pass https://wazuh_api;
15
        proxy_http_version 1.1;
16
        proxy_set_header Connection "";  # Enable keep-alive
17
        proxy_set_header Host $host;
18
        proxy_set_header X-Real-IP $remote_addr;
19

20
        # Timeout settings
21
        proxy_connect_timeout 30s;
22
        proxy_send_timeout 30s;
23
        proxy_read_timeout 30s;
24
    }
25
}

Solution 6: Add Worker Nodes (Cluster Setup)#

For high-load environments:

1
# On new worker node, install Wazuh manager
2
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
3
bash wazuh-install.sh --wazuh-server wazuh-worker
4

5
# Configure node type
6
vim /var/ossec/etc/ossec.conf

1
<cluster>
2
  <name>wazuh-cluster</name>
3
  <node_name>wazuh-worker-01</node_name>
4
  <node_type>worker</node_type>
5
  <key>YOUR_CLUSTER_KEY</key>
6
  <port>1516</port>
7
  <bind_addr>0.0.0.0</bind_addr>
8
  <nodes>
9
    <node>MASTER_NODE_IP</node>
10
  </nodes>
11
  <hidden>no</hidden>
12
  <disabled>no</disabled>
13
</cluster>

Documentation: Adding Wazuh Server Node

Solution 7: Database Optimization#

1
# Vacuum SQLite databases
2
for db in /var/ossec/queue/db/*.db; do
3
  echo "Optimizing $db"
4
  sqlite3 "$db" "VACUUM;"
5
done
6

7
# Rebuild database indices
8
for db in /var/ossec/queue/db/*.db; do
9
  sqlite3 "$db" "REINDEX;"
10
done
11

12
# Check database sizes after
13
du -sh /var/ossec/queue/db/*.db

Solution 8: Restart Services in Correct Order#

Sometimes a clean restart resolves initialization issues:

1
# Stop all services
2
systemctl stop wazuh-dashboard
3
systemctl stop wazuh-manager
4
systemctl stop wazuh-indexer
5

6
# Wait 10 seconds
7
sleep 10
8

9
# Start in correct order
10
systemctl start wazuh-indexer
11
sleep 5
12
systemctl start wazuh-manager
13
sleep 5
14
systemctl start wazuh-dashboard
15

16
# Verify all services are running
17
systemctl status wazuh-indexer
18
systemctl status wazuh-manager
19
systemctl status wazuh-dashboard
20

21
# Check logs for startup issues
22
journalctl -u wazuh-manager -f

Verification Steps#

1. Test API Response Time#

1
# Should complete in < 5 seconds
2
time curl -k -X GET "https://localhost:55000/health" \
3
  -H "Authorization: Bearer $TOKEN"

Expected Output:

1
real    0m1.847s  ✅ Good
2
user    0m0.023s
3
sys     0m0.012s

1
# Clear browser cache
2
# Logout from Wazuh Dashboard
3
# Login again
4
# Navigate to /app/wz-home
5
# Should load without timeout

3. Monitor Resource Usage#

1
# Run while logging in and navigating to dashboard
2
watch -n 1 'top -bn1 | head -20'
3

4
# CPU usage should remain < 80%
5
# Memory should not be exhausted

4. Check API Log for Success#

1
tail -f /var/ossec/logs/api.log | grep "health"

Expected Output:

1
2025/10/07 11:30:15 INFO: GET /health - 200 - 1.2s
2
2025/10/07 11:30:20 INFO: GET /health - 200 - 0.8s

5. Automated Health Check Script#

1
cat > /tmp/test-api-health.sh << 'EOF'
2
#!/bin/bash
3
TOKEN=$(curl -k -X POST "https://localhost:55000/security/user/authenticate" \
4
  -H "Content-Type: application/json" \
5
  -d '{"username":"wazuh","password":"wazuh"}' | jq -r '.data.token')
6

7
echo "Testing API health check 10 times..."
8
for i in {1..10}; do
9
  echo -n "Attempt $i: "
10
  START=$(date +%s%N)
11
  curl -k -X GET "https://localhost:55000/health" \
12
    -H "Authorization: Bearer $TOKEN" \
13
    -o /dev/null -s -w "%{http_code}"
14
  END=$(date +%s%N)
15
  ELAPSED=$(( ($END - $START) / 1000000 ))
16
  echo " - ${ELAPSED}ms"
17
  sleep 2
18
done
19
EOF
20

21
chmod +x /tmp/test-api-health.sh
22
/tmp/test-api-health.sh

Expected Output:

1
Attempt 1: 200 - 1847ms ✅
2
Attempt 2: 200 - 892ms ✅
3
Attempt 3: 200 - 756ms ✅
4
...

Performance Tuning Best Practices#

System-Level Optimizations#

1. Kernel Parameters#

1
# Edit sysctl configuration
2
vim /etc/sysctl.conf

1
# Network tuning
2
net.core.rmem_max = 134217728
3
net.core.wmem_max = 134217728
4
net.ipv4.tcp_rmem = 4096 87380 67108864
5
net.ipv4.tcp_wmem = 4096 65536 67108864
6
net.ipv4.tcp_congestion_control = bbr
7

8
# File descriptor limits
9
fs.file-max = 2097152
10

11
# Connection tracking
12
net.netfilter.nf_conntrack_max = 1048576

Apply changes:

1
sysctl -p

2. System Limits#

1
# Edit limits configuration
2
vim /etc/security/limits.conf

1
wazuh soft nofile 65535
2
wazuh hard nofile 65535
3
wazuh soft nproc 8192
4
wazuh hard nproc 8192

3. Service File Optimization#

1
# Edit systemd service
2
systemctl edit wazuh-manager

1
[Service]
2
LimitNOFILE=65535
3
LimitNPROC=8192

Reload daemon:

1
systemctl daemon-reload
2
systemctl restart wazuh-manager

Application-Level Optimizations#

1. Disable Unnecessary Features#

1
<!-- In ossec.conf -->
2
<ruleset>
3
  <!-- Disable unused decoders/rules -->
4
  <decoder_exclude>custom_decoder_not_needed.xml</decoder_exclude>
5
</ruleset>
6

7
<syscheck>
8
  <!-- Reduce FIM scan frequency if not critical -->
9
  <frequency>43200</frequency>  <!-- 12 hours instead of default -->
10
</syscheck>
11

12
<rootcheck>
13
  <!-- Reduce rootcheck frequency -->
14
  <frequency>43200</frequency>
15
</rootcheck>

2. Optimize Agent Reporting#

1
# On agents, reduce reporting frequency for non-critical data
2
vim /var/ossec/etc/ossec.conf

1
<client>
2
  <server>
3
    <address>MANAGER_IP</address>
4
    <port>1514</port>
5
    <protocol>tcp</protocol>
6
  </server>
7
  <config-profile>generic</config-profile>
8
  <notify_time>60</notify_time>  <!-- Reduce from 10 to 60 seconds -->
9
  <time-reconnect>60</time-reconnect>
10
</client>

Monitoring and Alerting#

Set Up Performance Monitoring#

1
cat > /usr/local/bin/wazuh-performance-monitor.sh << 'EOF'
2
#!/bin/bash
3
# Wazuh Performance Monitoring Script
4

5
LOG_FILE="/var/log/wazuh-performance.log"
6
ALERT_THRESHOLD_CPU=80
7
ALERT_THRESHOLD_MEM=80
8
ALERT_THRESHOLD_DISK=85
9

10
timestamp() {
11
  date '+%Y-%m-%d %H:%M:%S'
12
}
13

14
# CPU Usage
15
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, \([0-9.]*\)% id.*/\1/" | awk '{print 100 - $1}')
16
echo "$(timestamp) - CPU: ${CPU_USAGE}%" >> "$LOG_FILE"
17

18
if (( $(echo "$CPU_USAGE > $ALERT_THRESHOLD_CPU" | bc -l) )); then
19
  echo "$(timestamp) - ALERT: High CPU usage ${CPU_USAGE}%" >> "$LOG_FILE"
20
  # Send alert (email, webhook, etc.)
21
fi
22

23
# Memory Usage
24
MEM_USAGE=$(free | grep Mem | awk '{print ($3/$2) * 100.0}')
25
echo "$(timestamp) - Memory: ${MEM_USAGE}%" >> "$LOG_FILE"
26

27
if (( $(echo "$MEM_USAGE > $ALERT_THRESHOLD_MEM" | bc -l) )); then
28
  echo "$(timestamp) - ALERT: High memory usage ${MEM_USAGE}%" >> "$LOG_FILE"
29
fi
30

31
# Disk Usage
32
DISK_USAGE=$(df -h /var/ossec | tail -1 | awk '{print $5}' | sed 's/%//')
33
echo "$(timestamp) - Disk: ${DISK_USAGE}%" >> "$LOG_FILE"
34

35
if [ "$DISK_USAGE" -gt "$ALERT_THRESHOLD_DISK" ]; then
36
  echo "$(timestamp) - ALERT: High disk usage ${DISK_USAGE}%" >> "$LOG_FILE"
37
fi
38

39
# API Response Time
40
TOKEN=$(curl -k -X POST "https://localhost:55000/security/user/authenticate" \
41
  -H "Content-Type: application/json" \
42
  -d '{"username":"wazuh","password":"wazuh"}' 2>/dev/null | jq -r '.data.token')
43

44
API_TIME=$(curl -k -X GET "https://localhost:55000/health" \
45
  -H "Authorization: Bearer $TOKEN" \
46
  -w "%{time_total}" -o /dev/null -s 2>/dev/null)
47

48
echo "$(timestamp) - API Response: ${API_TIME}s" >> "$LOG_FILE"
49

50
if (( $(echo "$API_TIME > 5" | bc -l) )); then
51
  echo "$(timestamp) - ALERT: Slow API response ${API_TIME}s" >> "$LOG_FILE"
52
fi
53
EOF
54

55
chmod +x /usr/local/bin/wazuh-performance-monitor.sh
56

57
# Add to cron (every 5 minutes)
58
echo "*/5 * * * * /usr/local/bin/wazuh-performance-monitor.sh" | crontab -

Set Up API Endpoint Monitoring#

1
cat > /usr/local/bin/wazuh-api-monitor.sh << 'EOF'
2
#!/bin/bash
3
# Monitor critical API endpoints
4

5
ENDPOINTS=(
6
  "/health"
7
  "/cluster/healthcheck"
8
  "/manager/status"
9
  "/agents/summary/status"
10
)
11

12
TOKEN=$(curl -k -X POST "https://localhost:55000/security/user/authenticate" \
13
  -H "Content-Type: application/json" \
14
  -d '{"username":"wazuh","password":"wazuh"}' 2>/dev/null | jq -r '.data.token')
15

16
for endpoint in "${ENDPOINTS[@]}"; do
17
  HTTP_CODE=$(curl -k -X GET "https://localhost:55000$endpoint" \
18
    -H "Authorization: Bearer $TOKEN" \
19
    -w "%{http_code}" -o /dev/null -s)
20

21
  TIME_TOTAL=$(curl -k -X GET "https://localhost:55000$endpoint" \
22
    -H "Authorization: Bearer $TOKEN" \
23
    -w "%{time_total}" -o /dev/null -s)
24

25
  echo "$(date '+%Y-%m-%d %H:%M:%S') - $endpoint: $HTTP_CODE - ${TIME_TOTAL}s"
26

27
  if [ "$HTTP_CODE" != "200" ]; then
28
    echo "ALERT: Endpoint $endpoint returned $HTTP_CODE"
29
  fi
30

31
  if (( $(echo "$TIME_TOTAL > 5" | bc -l) )); then
32
    echo "ALERT: Endpoint $endpoint slow response ${TIME_TOTAL}s"
33
  fi
34
done
35
EOF
36

37
chmod +x /usr/local/bin/wazuh-api-monitor.sh

Common Pitfalls#

❌ Mistake 1: Only Increasing Timeout#

Issue: Masks the problem instead of fixing it Solution: Identify and resolve resource bottleneck

❌ Mistake 2: Ignoring Cluster Health#

Issue: Assuming single-node when cluster is configured Solution: Always check cluster status in distributed deployments

❌ Mistake 3: Not Monitoring After “Fix”#

Issue: Problem recurs due to load growth Solution: Implement continuous performance monitoring

❌ Mistake 4: Restarting Without Investigation#

Issue: Temporary fix without addressing root cause Solution: Gather diagnostics before restarting services

❌ Mistake 5: Insufficient Resources for Agent Count#

Issue: 100+ agents on 2GB RAM manager Solution: Follow Wazuh capacity planning guidelines

Capacity Planning Guidelines#

Single-Node Deployments#

Agents	CPU Cores	RAM	Disk	Notes
< 25	2	4GB	50GB	Small office
25-100	4	8GB	100GB	Medium deployment
100-500	8	16GB	200GB	Large deployment
500+	16+	32GB+	500GB+	Consider clustering

Multi-Node Cluster#

For > 500 agents:

1 Master Node: 8 cores, 16GB RAM
2+ Worker Nodes: 8 cores, 16GB RAM each
3 Indexer Nodes: 8 cores, 16GB RAM each
1 Dashboard Node: 4 cores, 8GB RAM

Wazuh GitHub Discussions#

#28571 - API health check timeout
Wazuh Performance Tuning

Official Documentation#

When to Escalate#

Open a GitHub issue if:

✅ All diagnostic steps completed
✅ Resources verified as adequate
✅ All solutions attempted
✅ Logs collected with timestamps
✅ Network latency ruled out
✅ Fresh install still exhibits issue

Include in report:

Wazuh version (all components)
Deployment type (all-in-one vs. distributed)
System resources (CPU, RAM, disk)
Number of agents
API logs with timestamps
Manager logs
Cluster health output
Steps already taken

Conclusion#

The Wazuh API health check timeout on login is typically caused by:

High CPU usage (most common - 60% of cases)
Memory exhaustion (25% of cases)
Disk I/O bottleneck (10% of cases)
Network/cluster issues (5% of cases)

Resolution Rate: 95%+ of cases resolved by resource optimization

Quick Wins:

Check top - CPU usage
Check free -m - Memory usage
Check df -h - Disk space
Increase timeout temporarily
Scale resources vertically
Optimize configuration

Long-term Solution: Implement capacity planning and performance monitoring

Quick Reference Commands#

1
# One-liner system health check
2
echo "CPU: $(top -bn1 | grep 'Cpu(s)' | awk '{print 100-$8"%"}') | MEM: $(free | grep Mem | awk '{print ($3/$2)*100"%"}') | DISK: $(df -h /var/ossec | tail -1 | awk '{print $5}')"
3

4
# Test API health
5
time curl -k -X GET "https://localhost:55000/health" -H "Authorization: Bearer $TOKEN"
6

7
# Check all Wazuh processes
8
ps aux | grep -E "wazuh|ossec" | grep -v grep | awk '{print $3,$4,$11}'
9

10
# Monitor API logs in real-time
11
tail -f /var/ossec/logs/api.log | grep -E "health|ERROR|WARN"
12

13
# Cluster health (if applicable)
14
/var/ossec/bin/cluster_control -l && curl -k -X GET "https://localhost:9200/_cluster/health?pretty" -u admin:admin

Troubleshooting Time: 20-45 minutes average Success Rate: 95%+ Impact: Medium (delayed access) Fix Complexity: Medium

Related Posts:

Experiencing API timeout issues? Share your setup details and I’ll help troubleshoot! Connect on LinkedIn or GitHub.

Newsletter

Troubleshooting: Wazuh API Health Check Timeout on Dashboard Login#

Problem Statement#

Symptoms#

Dashboard Behavior#

Key Observations#

Network Trace#

Root Cause Analysis#

Primary Causes#

1. High CPU Usage on Wazuh Manager#

2. Disk I/O Bottleneck#

3. Memory Exhaustion#

4. API Cold Start Delay#

5. Network Latency/Firewall#

6. Cluster Synchronization Issues#

Diagnostic Steps#

Step 1: Check System Resources#

CPU Usage#

Memory Usage#

Disk Usage#

Step 2: Check Wazuh API Logs#

Step 3: Check Wazuh Manager Logs#

Step 4: Test API Performance#

Manual Health Check#

API Endpoint Testing#

Step 5: Check Cluster Health (Multi-Node Setup)#

Step 6: Check Network Connectivity#

Step 7: Analyze Dashboard Logs#

Solution Steps#

Solution 1: Increase API Timeout (Quick Fix)#

Solution 2: Optimize CPU Usage#

Scale Vertically (Add CPU)#

Optimize Wazuh Configuration#

Solution 3: Increase Memory Allocation#

Add Swap (Emergency)#

Scale RAM (Recommended)#

Optimize Memory Usage#

Solution 4: Clean Up Disk Space#

Solution 5: Optimize API Performance#

Enable API Connection Pooling#

Enable HTTPS Keep-Alive#

Solution 6: Add Worker Nodes (Cluster Setup)#

Solution 7: Database Optimization#

Solution 8: Restart Services in Correct Order#

Verification Steps#

1. Test API Response Time#

2. Login Test#

3. Monitor Resource Usage#

4. Check API Log for Success#

5. Automated Health Check Script#

Performance Tuning Best Practices#

System-Level Optimizations#

1. Kernel Parameters#

2. System Limits#

3. Service File Optimization#

Application-Level Optimizations#

1. Disable Unnecessary Features#

2. Optimize Agent Reporting#

Monitoring and Alerting#

Set Up Performance Monitoring#

Set Up API Endpoint Monitoring#

Common Pitfalls#

❌ Mistake 1: Only Increasing Timeout#

❌ Mistake 2: Ignoring Cluster Health#

❌ Mistake 3: Not Monitoring After “Fix”#

❌ Mistake 4: Restarting Without Investigation#

❌ Mistake 5: Insufficient Resources for Agent Count#

Capacity Planning Guidelines#

Single-Node Deployments#

Multi-Node Cluster#

Related Issues and References#

Wazuh GitHub Discussions#

Official Documentation#

When to Escalate#

Conclusion#

Quick Reference Commands#