How to Fix “Wazuh Dashboard Server Is Not Ready Yet” (Step-by-Step)

The “Wazuh Dashboard Server Is Not Ready Yet” message typically appears in the browser when accessing the Wazuh Dashboard interface during startup or after a service disruption.

In most deployments, this screen replaces the normal login or analytics UI and indicates that the frontend cannot yet communicate with required backend services.

This issue is commonly observed in OpenSearch Dashboards-based Wazuh setups, where the dashboard loads but fails to complete initialization.

You’ll usually see it in the web UI loading screen while the system is still trying to establish connections to core services.

The problem matters because the dashboard is the primary interface for investigating alerts, visualizing security events, and managing SIEM data.

When it is stuck in this state, analysts lose visibility into security telemetry, even if the underlying Wazuh components are partially running.

References for baseline architecture and expected behavior:

• Wazuh Documentation (Architecture Overview)
• OpenSearch Dashboards Documentation

Reference for related troubleshooting context:

• Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

What “Wazuh Dashboard Server Is Not Ready Yet” Means

This error is essentially a service initialization failure state, not a single hard crash.

It indicates that the dashboard process has started but has not successfully completed its dependency checks and plugin initialization.

In practical terms, the dashboard service is running, but it is not yet fully operational because one or more critical backend dependencies are unavailable or unhealthy.

Dashboard is running but not fully initialized

The web server for Wazuh Dashboard (typically OpenSearch Dashboards) is up, but internal plugins and services are still loading.

During this phase, the UI remains blocked until health checks pass.

Failure to connect to core backend services

The dashboard depends on multiple backend components:

• Wazuh API: Provides endpoint data, alerts, and configuration access
• Indexer (OpenSearch / Elasticsearch backend): Stores and retrieves security events and logs
• Plugin system: Visualization and security apps must fully register before UI activation

If any of these fail to respond, the dashboard will remain in the “not ready” state.

Plugins not fully loaded or cluster not healthy

Even if services are technically running, the dashboard may still be blocked if:

• OpenSearch cluster health is yellow/red
• Required index patterns are missing
• Security dashboard plugins fail initialization
• TLS handshake between components is incomplete

This behavior is consistent with how OpenSearch Dashboards blocks UI rendering until all required services return healthy status responses.

Related Guides:

• Wazuh API Authentication Failed? Causes and Solutions
• How to Build a Wazuh Indexer Cluster

 Common Causes of the Error

This error almost always results from a dependency or startup sequencing issue in the stack.

Below are the most frequent root causes in real-world deployments.

Indexer (OpenSearch) not running or unhealthy

The most common cause is a failure in the indexer layer.

If the OpenSearch cluster is not fully initialized, the dashboard cannot retrieve required indices or metadata.

Symptoms include:

• Cluster status is red or yellow
• Missing security indices
• Slow or failing search queries

Wazuh manager not started properly

The Wazuh manager may fail to start due to:

• Rule compilation errors
• Disk space exhaustion
• Corrupted queue or state files

If the manager is not fully operational, the dashboard cannot fetch alerts or rule-based data.

Related Guide:

• How to Install a Wazuh Agent on Windows Server

Dashboard service started before dependencies

A classic startup race condition occurs when:

• OpenSearch starts slowly
• Wazuh manager initializes late
• Dashboard service boots first

This results in the dashboard entering a “waiting state” until backend services become available—or failing if timeouts are exceeded.

Certificate or TLS misconfiguration

Secure communication between components relies heavily on TLS.

Misconfiguration can break connectivity:

Common issues:

• Expired certificates
• Incorrect CA chain
• Hostname mismatch in certs
• Wrong paths in dashboard config

This typically prevents the dashboard from authenticating with OpenSearch or the Wazuh API.

Wrong credentials in configuration files

If credentials in opensearch_dashboards.yml or Wazuh configuration files are incorrect:

• Authentication to OpenSearch fails
• API requests are rejected
• Dashboard cannot complete initialization checks

Related Guide:

• Wazuh API Authentication Failed? Causes and Solutions

Port conflicts or firewall blocking communication

If required ports are blocked or already in use:

• Dashboard cannot reach OpenSearch (commonly 9200)
• Wazuh API becomes unreachable (commonly 55000)
• Internal plugin communication fails

This is especially common in hardened environments or multi-node deployments.

High CPU/memory causing delayed startup

Under heavy system load, services may technically start but fail to respond within expected time windows.

This leads to:

• Delayed index loading
• Timeout during plugin initialization
• Dashboard stuck in “not ready” state

This is often seen in under-provisioned environments or during large log ingestion spikes.

Related Guide:

• Why Is Wazuh Using High CPU? Troubleshooting Guide

Prerequisites Before Fixing

Before attempting any remediation for the “Wazuh Dashboard Server Is Not Ready Yet” error, ensure the environment is properly accessible and you have sufficient privileges to inspect and restart services.

You should have:

• SSH access to the server where the stack is deployed
• Root or sudo privileges to restart services and inspect logs
• A complete Wazuh stack installed, including:
  • Wazuh Manager
  • Wazuh Indexer
  • Wazuh Dashboard
• Familiarity with system service inspection tools such as:
  • systemctl (systemd-based installations)
  • Docker logs (docker logs) if running containerized deployments

Without these prerequisites, troubleshooting will be incomplete because this issue is almost always service-dependency related.

Step-by-Step Fix

This section follows a dependency-first recovery approach, starting from the backend layer and moving upward to the UI layer.

Check All Wazuh Services Status

Start by validating that all core services are active and running.

Run:

• systemctl status wazuh-manager
• systemctl status wazuh-indexer
• systemctl status wazuh-dashboard

Or in containerized environments:

• docker ps
• docker logs <container_name>

You are looking for:

• Active (running) state
• No repeated crashes or restarts
• No failed health checks

Identify:

• Stopped services
• Services stuck in “activating” state
• Any abnormal restart loops

Related Guide:

• How to Install a Wazuh Agent on Windows Server

Restart Services in Correct Order

Service startup order is critical in Wazuh deployments due to strict dependency chaining.

Restart in this order:

1. Indexer first
2. Manager second
3. Dashboard last

Commands (systemd):

systemctl restart wazuh-indexer
systemctl restart wazuh-manager
systemctl restart wazuh-dashboard

This ensures:

• OpenSearch backend is available before the dashboard connects
• Wazuh manager is ready to serve alerts and APIs
• Dashboard initialization does not fail due to missing dependencies

Verify Indexer Health

The Wazuh Indexer must be fully healthy before the dashboard can initialize.

Check cluster health:

curl -k https://localhost:9200/_cluster/health?pretty

Expected states:

• green → fully healthy (ideal)
• yellow → degraded but functional
• red → critical failure (dashboard will not load)

Also confirm:

• Indexer is reachable on port 9200
• No authentication or TLS errors in response

Inspect Dashboard Logs

The dashboard logs contain direct indicators of initialization failure.

Locate logs:

• /var/log/wazuh-dashboard/
• or via:
  • journalctl -u wazuh-dashboard

Look for errors such as:

• connection refused
• authentication failed
• unable to reach OpenSearch
• plugin initialization failed

These messages typically pinpoint whether the issue is:

• network-level
• authentication-related
• plugin or configuration-based

Related Guide:

• Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Validate Configuration Files

Misconfiguration in core YAML files is a frequent root cause.

Check:

• opensearch_dashboards.yml
• Wazuh API configuration files (commonly in /etc/wazuh-dashboard/ or /etc/wazuh/)

Validate:

• Correct hostnames
• Correct ports (e.g., 9200, 55000)
• Valid credentials
• No typos or mismatched service names

Even minor YAML indentation errors can prevent dashboard initialization entirely.

• Check Certificates (TLS Issues)

TLS misconfiguration is one of the most common hidden causes of this error.

Check for:

• Expired certificates
• Incorrect CA chain
• Hostname mismatch between services
• Wrong certificate paths in configuration files

If TLS handshake fails:

• Dashboard cannot authenticate with indexer
• API requests fail silently
• UI remains stuck in “not ready” state

In severe cases, you may need to regenerate certificates and redeploy trust chains across components.

Verify Network Connectivity

All components must be able to communicate over internal ports.

Test connectivity between:

• Dashboard ↔ Indexer (9200)
• Dashboard ↔ Wazuh API (55000)

Use:

curl -k https://<indexer-host>:9200
nc -zv <host> 9200

Check:

• Firewall rules (iptables, ufw)
• Cloud security groups (AWS, Azure, etc.)
• DNS resolution consistency

Check Resource Usage

High system load can delay or completely block dashboard initialization.

Inspect:

top
htop
free -m
df -h

Watch for:

• CPU saturation (>80–90%)
• Low available memory
• Swap exhaustion
• Disk full conditions

When resources are constrained:

• Indexer startup slows significantly
• Plugin initialization times out
• Dashboard remains stuck in “not ready” state

Docker / Kubernetes Deployments (If Applicable)

If your Wazuh stack is containerized, troubleshooting shifts to orchestration-level diagnostics.

Check container logs

Inspect logs for each service container:

docker logs wazuh-dashboard
docker logs wazuh-indexer
docker logs wazuh-manager

Look for:

• startup failures
• missing environment variables
• TLS or certificate errors
• service dependency failures

Ensure correct service dependencies in compose files

In Docker Compose deployments, verify:

• depends_on ordering is correctly set
• Health checks are defined for indexer and manager
• Dashboard does not start before backend services are healthy

A misconfigured dependency graph is one of the most common causes of startup race conditions.

Verify pod readiness in Kubernetes deployments

In Kubernetes environments:

Check:

kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>

Ensure:

• All pods are in Running state
• Readiness probes are passing
• No crash loops (CrashLoopBackOff)
• Services are correctly exposed via ClusterIP or Ingress

If readiness probes fail, the dashboard UI will remain inaccessible even though pods appear “running.”

Advanced Troubleshooting

If the standard service-level fixes do not resolve the “Wazuh Dashboard Server Is Not Ready Yet” error, the issue is likely related to corrupted indices, broken security plugins, or inconsistent cluster state within the Wazuh Indexer layer.

Rebuild dashboard index

A corrupted or partially initialized dashboard index can prevent the UI from completing startup.

Typical fix involves re-creating Wazuh dashboard-related indices in OpenSearch:

• Identify dashboard indices:

curl -k -u admin:admin https://localhost:9200/_cat/indices

• Delete and allow re-creation of problematic indices (only if necessary):

curl -k -u admin:admin -X DELETE "https://localhost:9200/wazuh-alerts-*"

After deletion:

• Restart dashboard service
• Allow indices to regenerate automatically

⚠️ Use caution: this may temporarily remove historical dashboard views.

Reset OpenSearch security plugin

Security plugin misconfiguration can block authentication between the dashboard and indexer.

Reset steps typically include:

• Reinitializing security configuration tools provided by OpenSearch
• Reapplying default security templates
• Restarting indexer and dashboard services afterward

This resolves:

• Authentication failures
• TLS handshake mismatches
• Role mapping issues

Reinitialize cluster settings

If cluster state becomes inconsistent (especially after abrupt shutdowns), the dashboard may never reach a “ready” state.

Steps:

• Verify cluster state:

curl -k https://localhost:9200/_cluster/state?pretty

• If corrupted or incomplete:
  • Restart all indexer nodes
  • Allow cluster to reform
  • Confirm green status

In multi-node setups, ensure:

• Master node election completes successfully
• All nodes join cluster without timeout errors

Clean cached dashboard data

The Wazuh Dashboard stores cached UI state that can become stale after upgrades or crashes.

Clear cache:

• Stop dashboard service
• Remove cache directories (commonly under /var/lib/wazuh-dashboard/ or /usr/share/wazuh-dashboard/data/)
• Restart service

This resolves:

• Stuck loading screens
• Broken plugin initialization
• Old configuration conflicts

Prevention Tips

Preventing this error is primarily about maintaining service dependency integrity and cluster health stability across the Wazuh stack.

Always start services in correct order

Maintain strict startup sequence:

1. Wazuh Indexer
2. Wazuh Manager
3. Wazuh Dashboard

This prevents race conditions during initialization.

 Monitor indexer health regularly

Continuously monitor:

• Cluster status (green/yellow/red)
• Index growth
• Shard allocation

Use:

• OpenSearch _cluster/health API
• Built-in Wazuh monitoring dashboards

 Automate health checks

Implement:

• Cron-based service checks
• Prometheus + Grafana monitoring (optional)
• Alerting on service downtime or high latency

Key metrics:

• Indexer response time
• Dashboard HTTP status
• Wazuh API availability

Keep certificates valid and rotated

TLS issues are a leading hidden cause of dashboard startup failures.

Best practices:

• Rotate certificates before expiry
• Maintain consistent CA trust chain across components
• Validate hostname consistency in cert SAN fields

Avoid resource starvation (CPU/RAM tuning)

Ensure adequate resources for:

• Wazuh Indexer (most resource-intensive component)
• Wazuh Manager rule processing
• Dashboard plugin initialization

Recommended:

• Avoid sustained CPU >80%
• Ensure sufficient heap allocation for indexer
• Prevent disk saturation (especially /var/lib partitions)

Frequently Asked Questions (FAQ)

Question: Why does Wazuh dashboard say “not ready yet” after reboot?

This usually happens because backend services (especially the indexer) take longer to start than the dashboard.

The UI loads first but cannot complete initialization until dependencies are healthy.

Question: How long should Wazuh dashboard take to start?

In a healthy environment, startup typically takes 30 seconds to 2 minutes, depending on system resources and index size.

Delays beyond this usually indicate backend issues.

Question: Can OpenSearch cause this error?

Yes. The Wazuh Indexer is the most common root cause. If the cluster is red, slow, or unreachable, the dashboard will remain stuck.

 Question: Do I need to restart all Wazuh services?

In most cases, yes. A full restart in correct order (indexer → manager → dashboard) ensures dependency alignment and clears transient startup states.

Question: Is this error related to certificates or SSL?

Yes. TLS misconfiguration is a frequent hidden cause. Expired or mismatched certificates between dashboard, indexer, and API can block initialization entirely.

Conclusion

The “Wazuh Dashboard Server Is Not Ready Yet” error almost always stems from broken or incomplete service dependencies rather than a single fault.

The most critical areas to verify are:

• Correct service startup order
• Health of the Wazuh Indexer
• Review of dashboard and indexer logs
• Validity of TLS certificates and authentication configuration

Ultimately, the Wazuh architecture is tightly coupled, meaning the dashboard depends heavily on the indexer and manager being fully operational before it can initialize.

Proactive monitoring of service health, resource usage, and certificate validity is the most effective way to prevent this issue from recurring in production environments.