If you’ve deployed Wazuh and are greeted with the frustrating “Kibana server is not ready yet” message instead of the dashboard, you’re not alone.
Although modern Wazuh releases use Wazuh Dashboard rather than Kibana as the official interface, the dashboard is built on OpenSearch Dashboards (a fork of Kibana).
As a result, administrators still frequently encounter and search for the well-known “Kibana server is not ready yet” error message, especially after upgrades, reboots, configuration changes, or infrastructure failures.
In most cases, this message doesn’t indicate a problem with the dashboard itself.
Instead, it means one or more backend services that the dashboard depends on haven’t finished initializing or are unavailable.
The root cause may be an unhealthy Wazuh Indexer cluster, authentication failures, TLS certificate issues, damaged indices, insufficient system resources, or communication problems between services.
A typical Wazuh deployment consists of several tightly integrated components:
- Wazuh Dashboard, which provides the web interface.
- Wazuh Indexer (OpenSearch), which stores alerts, inventories, and dashboard data.
- Wazuh Manager, which collects, analyzes, and correlates security events.
- Filebeat, which forwards alerts from the manager to the indexer.
Because these services depend on one another, a failure in one layer often prevents the dashboard from completing its startup sequence.
In this guide, you’ll learn what the error actually means, why it occurs in Wazuh environments, how to identify the underlying cause, and the exact steps to restore the dashboard. You’ll also learn preventive best practices to reduce the likelihood of the issue occurring again in production.
How to Fix “Wazuh Dashboard Server Is Not Ready Yet” (Step-by-Step) guide
Understanding the Error
What Does “Kibana Server Is Not Ready Yet” Mean?
The message “Kibana server is not ready yet” simply means that the dashboard application has started, but it has not completed its initialization process.
During startup, Wazuh Dashboard performs several validation checks before allowing users to log in.
These checks include:
- Establishing a secure connection to Wazuh Indexer
- Verifying cluster health
- Loading dashboard plugins
- Authenticating service credentials
- Initializing saved objects and index patterns
- Confirming required system indices are accessible
If any of these operations fail or take too long, the dashboard remains in a waiting state and continues displaying the “server is not ready yet” page.
This behavior is intentional and it prevents administrators from accessing a partially initialized or inconsistent dashboard.
Dashboard Startup Sequence
When Wazuh Dashboard starts, it follows a predictable initialization workflow:
- Read the dashboard configuration.
- Initialize installed plugins.
- Establish TLS connections.
- Authenticate against Wazuh Indexer.
- Verify cluster health.
- Load saved objects.
- Initialize application services.
- Start accepting user requests.
Failure at any stage halts the startup process until the issue is resolved.
Dependency on Wazuh Indexer
The dashboard cannot function independently.
Every visualization, search query, alert, inventory page, and security event displayed in the interface is retrieved from Wazuh Indexer.
If the indexer is unavailable, overloaded, or unhealthy, the dashboard has nowhere to retrieve its data.
Even if the dashboard service itself is running, it will remain unavailable until it successfully communicates with the indexer.
Saved Object Initialization
During startup, the dashboard loads its internal saved objects, including:
- Dashboards
- Visualizations
- Data views
- Security settings
- Plugin metadata
- Application configuration
If these indices become corrupted or inaccessible, initialization may fail and the dashboard will never reach the ready state.
Plugin Loading Process
Wazuh Dashboard loads both built-in OpenSearch Dashboards plugins and Wazuh-specific plugins during startup.
Each plugin must initialize successfully before the application becomes available.
Plugin failures can occur because of:
- Missing dependencies
- Version mismatches
- Corrupted configuration
- Authentication failures
- Unavailable backend services
A single plugin failure may delay or completely block dashboard startup.
How Wazuh Dashboard Depends on Other Services
Wazuh Dashboard
This is the web interface administrators use to investigate alerts, manage agents, monitor vulnerabilities, and configure the platform.
Although users interact primarily with the dashboard, it acts mainly as a frontend that depends on several backend services.
Wazuh Indexer
The indexer is the most critical dependency.
It stores:
- Security alerts
- Agent inventories
- Vulnerability data
- Dashboard configuration
- Saved objects
- Search indices
If the indexer is unavailable or unhealthy, the dashboard cannot complete initialization.
Wazuh Manager
The manager analyzes logs, applies detection rules, executes active responses, and generates alerts.
While the dashboard may still load if the manager is temporarily unavailable, missing manager connectivity often leads to incomplete functionality and missing security data.
Filebeat
Filebeat transfers alerts generated by Wazuh Manager into Wazuh Indexer.
If Filebeat stops forwarding events, existing dashboards may still load, but new security alerts will not appear.
Resolving Filebeat Connection Refused Errors in Wazuh Deployments guide
TLS Communication
Secure TLS communication exists between multiple Wazuh components.
Certificates must be:
- Valid
- Trusted
- Unexpired
- Properly configured
Certificate validation failures commonly prevent the dashboard from connecting to Wazuh Indexer.
Authentication
The dashboard authenticates with Wazuh Indexer using service credentials.
Incorrect usernames, passwords, security roles, or expired credentials can prevent successful startup.
Common Causes of the Error
Although the message appears generic, the underlying causes usually fall into one of several categories.
Wazuh Indexer Is Down
This is by far the most common cause.
If the indexer service has stopped or failed to start, the dashboard has no backend to connect to.
Cluster Health Is Red
A red cluster status indicates one or more primary shards are unavailable.
Until cluster health improves, dashboard initialization may stall or fail completely.
Index Corruption
Damaged system indices or corrupted saved objects can prevent initialization from completing successfully.
Unexpected shutdowns, disk failures, or interrupted upgrades often contribute to index corruption.
Authentication Failures
Incorrect credentials between Wazuh Dashboard and Wazuh Indexer can stop the dashboard during startup.
Authentication problems are especially common after password rotations or security configuration changes.
TLS Certificate Problems
Expired, invalid, or mismatched certificates frequently cause secure connections to fail.
Because all communication is encrypted, even small certificate configuration errors can prevent startup.
Network Connectivity Issues
Firewall rules, DNS failures, routing problems, or closed ports can interrupt communication between Wazuh services.
Even if every service is running locally, network misconfigurations may still prevent successful initialization.
Disk Space Exhaustion
When disks become full, OpenSearch may stop writing data or refuse to allocate shards.
This often results in degraded cluster health and dashboard startup failures.
Memory Shortages
Insufficient RAM or improperly configured JVM heap settings can cause Wazuh Indexer to crash, restart repeatedly, or become unresponsive.
Memory pressure is particularly common in smaller virtual machines running multiple Wazuh services.
Version Incompatibility
Mixing incompatible versions of Wazuh Dashboard, Wazuh Indexer, Filebeat, or plugins can lead to initialization failures.
Version consistency across all components is essential after upgrades.
Plugin Initialization Failures
A plugin that fails to load because of configuration errors, dependency issues, or incompatible versions can prevent the dashboard from reaching the ready state.
According to the OpenSearch documentation, dashboard startup depends on successful plugin initialization and healthy communication with the backend cluster.
OpenSearch Dashboards Troubleshooting — https://opensearch.org/docs/latest/
The Wazuh documentation also recommends verifying indexer health, service status, and dashboard logs as the first steps when diagnosing dashboard startup issues.
Industry experts at Elastic likewise note that the “server is not ready yet” message almost always points to backend initialization issues rather than a frontend problem.
Before You Start Troubleshooting
Proper preparation can significantly reduce troubleshooting time.
Before making configuration changes or restarting services, collect information about your environment and document the current state of the system.
Verify Your Environment
Begin by confirming several key details.
Wazuh Version
Record the installed Wazuh version for:
- Dashboard
- Indexer
- Manager
- Agents (if relevant)
Many issues are version-specific, particularly after upgrades.
Operating System
Document the operating system and distribution.
Service names, file locations, package managers, and log paths vary between Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, and other supported platforms.
Single-Node vs Multi-Node Deployment
Determine whether you’re using:
- Single-node deployment
- High-availability cluster
- Distributed production deployment
Troubleshooting cluster synchronization differs significantly from troubleshooting standalone installations.
Recent Upgrades or Configuration Changes
Ask whether any of the following occurred shortly before the problem appeared:
- Version upgrade
- Certificate replacement
- Password change
- Plugin installation
- Firewall modification
- Storage expansion
- Operating system update
- Configuration edits
Many startup failures can be traced directly to a recent infrastructure change.
Record the Current Symptoms
Before attempting fixes, capture as much information as possible.
Exact Error Message
Take note of:
- Browser message
- HTTP status codes
- Dashboard logs
- Console errors
Small wording differences often point to different root causes.
Service Status
Verify the status of:
- Wazuh Dashboard
- Wazuh Indexer
- Wazuh Manager
- Filebeat
Understanding which service failed first helps narrow the investigation.
Recent Logs
Collect recent logs from all major services before restarting anything.
Early startup errors frequently disappear after services restart, making initial log collection especially valuable.
Recent Maintenance Activities
Finally, document any maintenance performed within the last few days, including:
- Server reboots
- Planned upgrades
- Storage maintenance
- Security patches
- Certificate renewals
- Configuration changes
Having a clear timeline often makes identifying the root cause much easier later in the troubleshooting process.
Step 1: Verify Wazuh Dashboard Service Status
The first step is to confirm that the Wazuh Dashboard service is actually running.
The “Kibana server is not ready yet” message often appears when the service has failed during startup or is repeatedly crashing due to configuration or dependency issues.
Even if the web interface is accessible, the underlying service may still be stuck in an initialization loop.
Check Dashboard Service
On most Linux distributions, you can verify the service status with:
sudo systemctl status wazuh-dashboard
A healthy service should report an active (running) state.
If the service is inactive, failed, or continually restarting, note any error messages displayed by systemctl, as they often point directly to the underlying problem.
You can also check whether the service starts automatically after boot:
sudo systemctl is-enabled wazuh-dashboard
Restart if Necessary
If the dashboard is not running, try restarting it:
sudo systemctl restart wazuh-dashboard
After restarting, check its status again:
sudo systemctl status wazuh-dashboard
If the service immediately returns to a failed state, avoid repeatedly restarting it. Instead, investigate the logs to identify the root cause.
Review Startup Failures
Systemd often records useful startup errors.
View recent service logs using:
sudo journalctl -u wazuh-dashboard -n 100 --no-pager
Look for messages mentioning:
- Failed plugin initialization
- TLS handshake failures
- Authentication errors
- Configuration parsing errors
- Connection timeouts
- Permission issues
The earliest error in the log is frequently the most valuable clue.
Examine Dashboard Logs
While journalctl provides service-level information, the dashboard logs usually contain more detailed application errors.
Default Log Locations
Depending on your installation method, dashboard logs are commonly located in:
/var/log/wazuh-dashboard/
/usr/share/wazuh-dashboard/logs/
Some deployments may rely primarily on the systemd journal instead of dedicated log files.
Review the most recent entries:
sudo tail -100 /var/log/wazuh-dashboard/wazuh-dashboard.log
Adjust the path if your installation stores logs elsewhere.
Common Startup Errors
Common log entries include:
- Unable to connect to OpenSearch
- Failed authentication
- Certificate validation failures
- Plugin initialization timeout
- Saved object migration failure
- Cluster unavailable
- Connection refused
Each message narrows the scope of your troubleshooting.
Plugin Loading Failures
If a plugin fails during initialization, you may see errors similar to:
Plugin initialization failed
Plugin did not start
Unable to load plugin
Plugin failures commonly occur after:
- Version upgrades
- Incomplete package installations
- Corrupted configuration files
- Incompatible plugin versions
If you recently upgraded Wazuh, verify that all components were upgraded together.
Authentication Errors
Authentication issues usually appear as:
Authentication failed
401 Unauthorized
Security exception
Invalid credentials
These indicate that the dashboard cannot authenticate with Wazuh Indexer.
Verify:
- Username
- Password
- Security configuration
- Authentication backend
- TLS certificates
Authentication failures should be resolved before investigating other dashboard components.
Step 2: Verify Wazuh Indexer Is Running
The dashboard cannot finish loading unless Wazuh Indexer is operational.
Since the dashboard retrieves alerts, saved objects, and configuration data directly from the indexer, any indexer outage will leave the interface stuck on the startup screen.
Check Indexer Service Status
Verify the indexer service:
sudo systemctl status wazuh-indexer
A healthy service should show:
Active: active (running)
If it reports failed, inactive, or activating indefinitely, further investigation is required.
Review Indexer Logs
Indexer logs usually provide the most accurate explanation for startup failures.
Typical log locations include:
/var/log/wazuh-indexer/
/var/log/opensearch/
View recent entries:
sudo tail -100 /var/log/wazuh-indexer/wazuh-cluster.log
Look for errors involving:
- Out of memory
- Disk allocation
- Shard failures
- Certificate validation
- Security initialization
- JVM crashes
- Bootstrap failures
These issues commonly prevent the dashboard from connecting successfully.
How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes
Restart the Indexer
If the service is stopped, restart it:
sudo systemctl restart wazuh-indexer
Then confirm it remains running:
sudo systemctl status wazuh-indexer
If the service immediately exits again, avoid repeated restarts and investigate the logs first.
Repeated failures often indicate:
- Corrupted indices
- Memory exhaustion
- Disk problems
- Configuration errors
Confirm the Indexer Is Listening on the Correct Port
The dashboard must be able to communicate with the indexer over its HTTPS interface.
Verify that the service is listening:
sudo ss -tulnp | grep 9200
or
sudo netstat -tulnp | grep 9200
A healthy result typically shows the indexer listening on TCP port 9200.
If nothing is listening, the indexer either failed to start or is configured to use a different interface or port.
Step 3: Check Cluster Health
Even if Wazuh Indexer is running, the cluster itself may not be healthy enough for the dashboard to initialize.
The dashboard waits until required indices become available before completing startup.
Verify Cluster Status
Query the cluster health API:
curl -k -u admin:password https://localhost:9200/_cluster/health?pretty
Replace the credentials with those configured in your environment.
The response includes the cluster status along with important metrics such as active shards, node count, and pending tasks.
Understand Green, Yellow, and Red States
Cluster health is represented by three colors.
Green
Everything is healthy.
- All primary shards allocated
- All replica shards allocated
- Dashboard should initialize normally
Yellow
Primary shards are healthy, but some replica shards are unavailable.
This commonly occurs in single-node deployments and is usually not severe.
Red
One or more primary shards are unavailable.
This is a critical condition and frequently causes the dashboard to remain stuck on the startup screen.
Identify Unassigned Shards
Determine whether shards are unassigned:
curl -k -u admin:password https://localhost:9200/_cat/shards?v
Look for entries with:
UNASSIGNED
Unassigned primary shards are especially problematic because they make portions of the cluster unavailable.
Possible causes include:
- Full disks
- Failed nodes
- Corrupted indices
- Allocation restrictions
- Failed recoveries
Resolve Cluster Health Issues
The appropriate solution depends on the underlying cause.
Common corrective actions include:
- Free disk space
- Restart failed nodes
- Restore missing nodes
- Repair damaged indices
- Reallocate shards
- Increase available memory
- Remove allocation blocks
After making corrections, verify the cluster health again.
A healthy cluster significantly increases the likelihood that the dashboard will complete its startup sequence successfully.
Step 4: Verify Connectivity Between Dashboard and Indexer
If both services are running but the dashboard still displays “Kibana server is not ready yet,” the next step is to verify communication between them.
Network connectivity issues are surprisingly common, particularly after firewall changes, DNS updates, or server migrations.
Test Network Connectivity
From the dashboard server, test connectivity to the indexer.
For example:
ping indexer-hostname
or
curl -k https://indexer-hostname:9200
If the connection fails, investigate network routing, firewalls, or hostname configuration.
Verify Hostname Resolution
Confirm that the dashboard resolves the indexer’s hostname correctly.
Use:
nslookup indexer-hostname
or
host indexer-hostname
or
dig indexer-hostname
Incorrect DNS records or outdated /etc/hosts entries frequently lead to connection failures.
Ensure that the resolved IP address matches the expected indexer server.
Check Firewall Rules
Verify that firewalls allow communication between the dashboard and the indexer.
Common firewall tools include:
- firewalld
- UFW
- iptables
- Cloud security groups
- Network ACLs
If traffic on port 9200 is blocked, the dashboard cannot communicate with the backend cluster.
Also verify that no intermediate firewall or load balancer is interrupting TLS traffic.
Confirm Port Accessibility
Finally, verify that TCP port 9200 is reachable from the dashboard server.
You can test this using:
nc -zv indexer-hostname 9200
or
telnet indexer-hostname 9200
A successful connection confirms that:
- Network routing is functioning.
- Firewalls permit traffic.
- The indexer is listening on the expected port.
If the port is inaccessible, focus on resolving the networking issue before continuing with higher-level troubleshooting.
According to the Wazuh documentation, reliable communication between the dashboard and indexer is a prerequisite for successful dashboard initialization.
Step 5: Validate Dashboard Configuration
If Wazuh Dashboard and Wazuh Indexer are both running and network connectivity has been verified, the next step is to inspect the dashboard configuration itself.
A single incorrect setting in the configuration file can prevent the dashboard from completing its startup sequence.
Review opensearch_dashboards.yml
The primary configuration file is typically located at:
/etc/wazuh-dashboard/opensearch_dashboards.yml
Open the file using your preferred editor:
sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml
Carefully review every setting related to:
- Indexer hosts
- Authentication
- TLS certificates
- Security plugin
- Network configuration
Pay particular attention to values that may have changed after a recent upgrade or migration.
Verify Indexer Hosts
Locate the configured OpenSearch hosts.
For example:
opensearch.hosts:
- https://indexer.example.com:9200
Verify that:
- The hostname is correct.
- The port number is correct.
- The protocol (HTTP vs HTTPS) matches your deployment.
- The server is reachable.
Using an outdated hostname is a common cause of startup failures.
Check Authentication Credentials
Confirm that the configured service account credentials are valid.
Verify:
- Username
- Password
- Authentication method
- Security configuration
If passwords were recently rotated, update the dashboard configuration accordingly.
Authentication failures usually generate 401 Unauthorized or 403 Forbidden errors in the dashboard logs.
Confirm SSL Settings
Review all SSL-related settings.
Typical options include:
opensearch.ssl.verificationMode
opensearch.ssl.certificateAuthorities
server.ssl.enabled
Ensure they match your deployment.
For example:
- HTTPS should use TLS certificates.
- HTTP deployments should not reference missing certificates.
- Certificate verification mode should match your security requirements.
Avoid disabling certificate verification except for temporary testing.
Validate Certificate Paths
Confirm that every configured certificate path actually exists.
For example:
/etc/wazuh-dashboard/certs/
Verify:
- CA certificate
- Client certificate
- Private key
A missing certificate file prevents secure communication during startup.
Verify Configuration Syntax
Even a small formatting error can stop the dashboard from loading.
Common mistakes include:
- Incorrect indentation
- Missing quotation marks
- Duplicate keys
- Invalid YAML syntax
If you recently edited the configuration file, carefully compare your changes against a known working version.
The Wazuh documentation recommends validating configuration changes before restarting production services.
Step 6: Check SSL/TLS Certificate Problems
TLS certificate problems are among the most common causes of dashboard startup failures.
If the dashboard cannot establish a trusted encrypted connection with Wazuh Indexer, initialization stops immediately.
Validate Certificate Expiration
First, confirm that certificates have not expired.
Use OpenSSL:
openssl x509 -in dashboard.pem -noout -dates
Review:
- Not Before
- Not After
Expired certificates must be replaced before secure communication can resume.
Verify Certificate Chain
A valid server certificate is only part of the trust relationship.
Ensure that:
- The complete certificate chain is installed.
- Intermediate certificates are present.
- The correct certificate authority (CA) is trusted.
Incomplete chains frequently produce TLS handshake failures.
Confirm Hostname Matching
The certificate’s Common Name (CN) or Subject Alternative Name (SAN) must match the hostname used by Wazuh Dashboard.
For example:
Certificate:
indexer01.company.local
Dashboard connects to:
indexer.company.local
This mismatch causes certificate validation to fail.
Always connect using the hostname included in the certificate.
Check File Permissions
The dashboard service must be able to read every certificate and private key.
Verify ownership:
ls -l /etc/wazuh-dashboard/certs/
Typical issues include:
- Incorrect ownership
- Insufficient read permissions
- Missing private keys
Avoid making private keys world-readable.
Test Secure Connections
You can verify TLS connectivity using OpenSSL:
openssl s_client -connect indexer.example.com:9200
A successful handshake confirms:
- TLS negotiation succeeded.
- The certificate chain is trusted.
- The server responded correctly.
If the handshake fails, investigate certificate configuration before proceeding.
Step 7: Verify Authentication and Security Configuration
Once TLS has been verified, ensure that authentication between Wazuh Dashboard and Wazuh Indexer is functioning correctly.
Even valid certificates cannot compensate for incorrect credentials or security configuration.
Check Internal Users
Review the configured service account.
Confirm:
- Username exists.
- Password is correct.
- Account is enabled.
- Account is not locked.
If authentication is managed through OpenSearch Security, verify that the internal user database is synchronized.
Verify Password Changes
Password changes are a frequent source of dashboard startup failures.
Ask the following questions:
- Was the admin password recently changed?
- Were dashboard credentials updated?
- Were configuration files modified?
- Were security changes deployed to every node?
If passwords differ between services, authentication will fail.
Validate Security Plugin Configuration
Review the OpenSearch Security plugin configuration.
Ensure:
- Security plugin initialized successfully.
- Configuration files are valid.
- Authentication backend is functioning.
- TLS settings match across services.
Security initialization errors often appear in the indexer logs before the dashboard reports any problems.
Confirm Role Permissions
The dashboard service account requires sufficient permissions to:
- Read cluster information
- Access system indices
- Load saved objects
- Read dashboard configuration
- Query security indices
Missing privileges frequently produce authorization errors even when authentication succeeds.
According to OpenSearch Security documentation, improperly assigned roles are one of the most common causes of dashboard access problems.
Step 8: Inspect Disk Space and System Resources
Resource shortages frequently prevent Wazuh services from starting correctly.
Even if every configuration file is correct, insufficient hardware resources can leave the dashboard permanently stuck during initialization.
Check Available Disk Space
Verify available storage:
df -h
Pay particular attention to:
- Root filesystem
- Data volumes
- OpenSearch data directories
- Log partitions
OpenSearch may refuse to allocate shards when disk usage exceeds configured watermarks.
Freeing disk space often restores normal cluster operation.
Verify Memory Usage
Check current memory utilization:
free -h
Also examine swap usage.
Low available memory can cause:
- JVM crashes
- Slow garbage collection
- Service restarts
- Cluster instability
If memory is consistently exhausted, consider increasing available RAM.
Monitor CPU Utilization
Review current processor usage:
top
or
htop
High CPU utilization may indicate:
- Index recovery
- Heavy ingestion
- Large searches
- Plugin initialization
- Excessive garbage collection
Sustained CPU saturation can significantly delay dashboard startup.
Review JVM Heap Usage
Since Wazuh Indexer runs on Java, heap configuration is critical.
Check heap settings and garbage collection behavior.
If heap usage remains close to maximum capacity, you may observe:
- Long startup times
- Frequent GC pauses
- OutOfMemory errors
- Node instability
Increasing JVM heap appropriately can greatly improve cluster stability.
The OpenSearch project recommends allocating approximately 50% of available system memory to the JVM heap while leaving sufficient RAM for the operating system and filesystem cache.
Step 9: Verify Index Health
Healthy services and correct configuration are not enough if the underlying indices are damaged.
Corrupted or unavailable indices often prevent Wazuh Dashboard from loading saved objects during startup.
List Existing Indices
Display all indices:
curl -k -u admin:password https://localhost:9200/_cat/indices?v
Review:
- Index names
- Health status
- Number of shards
- Document counts
Missing system indices should be investigated immediately.
Identify Corrupted Indices
Signs of index corruption include:
- Failed recovery
- Read errors
- Missing primary shards
- Continuous allocation failures
- Repeated startup exceptions
The indexer logs typically identify which index is causing the problem.
Corruption often follows:
- Unexpected power failures
- Disk failures
- Interrupted upgrades
- Filesystem errors
Check Index Status
Pay close attention to the health column.
Common values include:
- Green
- Yellow
- Red
Red system indices, particularly those used by the dashboard, are a common reason for the “Kibana server is not ready yet” message.
You can obtain additional details using:
curl -k -u admin:password https://localhost:9200/_cluster/allocation/explain?pretty
This API helps determine why shards cannot be allocated.
Repair or Recreate Problematic Indices
The appropriate recovery method depends on the severity of the issue.
Possible approaches include:
- Restoring from a snapshot
- Repairing shard allocation
- Deleting corrupted test indices
- Rebuilding dashboard indices
- Reindexing damaged data
Avoid deleting production system indices unless you fully understand the consequences and have verified backups.
If index corruption occurred after a failed upgrade or migration, restoring from a recent snapshot is generally the safest recovery strategy.
How to Clear Stuck Migration Indices in Wazuh Dashboard guide
Step 10: Verify Filebeat Is Working Correctly
Although Filebeat is not directly responsible for displaying the Wazuh Dashboard, it plays an essential role in forwarding alerts from the Wazuh Manager to the Wazuh Indexer.
If Filebeat is misconfigured or unable to communicate with the indexer, it may indicate broader connectivity or authentication problems that also affect the dashboard.
Check Filebeat Service
Begin by confirming that the Filebeat service is running.
sudo systemctl status filebeat
A healthy service should report:
Active: active (running)
If the service has stopped or repeatedly crashes, investigate the logs before attempting multiple restarts.
If necessary, restart Filebeat:
sudo systemctl restart filebeat
Then verify that it remains active.
Review Filebeat Logs
Filebeat logs often reveal communication problems with Wazuh Indexer.
On most systems, review recent entries with:
sudo journalctl -u filebeat -n 100 --no-pager
or
sudo tail -100 /var/log/filebeat/filebeat
Look for messages such as:
- Connection refused
- TLS handshake failed
- Authentication failed
- Failed to publish events
- Output unavailable
- Backoff retry
These errors usually point to networking, authentication, or certificate issues.
Resolving Filebeat Connection Refused Errors in Wazuh Deployments guide
Confirm Data Is Reaching the Indexer
Next, verify that Filebeat is successfully indexing data.
You can check for recent documents using the OpenSearch APIs or inspect the dashboard once it becomes available.
If Filebeat is running but no new events appear, investigate:
- Output configuration
- Network connectivity
- Authentication
- TLS certificates
- Index permissions
A healthy Filebeat instance should continuously publish new security events.
Validate Filebeat Configuration
Review the Filebeat configuration file.
Typical location:
/etc/filebeat/filebeat.yml
Verify:
- Output hosts
- Username
- Password
- TLS settings
- Certificate paths
- Index names
If you’ve recently upgraded Wazuh or OpenSearch, ensure that the Filebeat configuration matches the new environment.
Step 11: Check Version Compatibility
Version mismatches are a common cause of startup failures after upgrades.
All Wazuh components should belong to the same supported release whenever possible.
Verify Component Versions
Determine the installed version of:
- Wazuh Dashboard
- Wazuh Indexer
- Wazuh Manager
- Filebeat
- OpenSearch plugins
Running mixed versions can introduce incompatible APIs or plugin behavior.
Confirm Supported Version Matrix
Compare your deployment against the official compatibility matrix.
Verify that:
- Dashboard version matches the Indexer.
- Manager version matches the agents.
- Filebeat version is supported.
- Installed plugins are compatible.
Unsupported combinations frequently produce initialization failures that appear as generic dashboard startup errors.
Identify Upgrade-Related Problems
If the error appeared immediately after an upgrade, investigate:
- Incomplete package upgrades
- Interrupted migrations
- Old configuration files
- Unsupported plugins
- Missing migration steps
Review upgrade logs carefully.
Many startup failures occur because one component was upgraded while another remained on an older release.
How to Stop the Infinite Wazuh Login Loop After a Version Upgrade guide
Step 12: Restart Services in the Correct Order
Once configuration issues have been corrected, restart the services in the proper sequence.
Restarting components in the wrong order can temporarily recreate dependency failures.
Recommended Restart Sequence
The recommended order is:
- Wazuh Indexer
- Wazuh Manager
- Filebeat
- Wazuh Dashboard
Allow each service to initialize fully before proceeding to the next.
Wazuh Indexer
Restart the indexer first.
sudo systemctl restart wazuh-indexer
Wait until:
- Service is active
- Cluster health is acceptable
- Port 9200 is responding
Do not continue until the backend is healthy.
Wazuh Manager
Restart the manager.
sudo systemctl restart wazuh-manager
Confirm that:
- Manager starts successfully
- No configuration errors appear
- Agents begin reconnecting
Filebeat
Restart Filebeat.
sudo systemctl restart filebeat
Verify that:
- Output connections succeed
- Events are being published
- No authentication or TLS errors appear
Wazuh Dashboard
Restart the dashboard last.
sudo systemctl restart wazuh-dashboard
If all backend services are functioning correctly, the dashboard should complete its initialization successfully.
Verify Each Service Before Continuing
After each restart, confirm:
- Service status
- Log output
- Network connectivity
- Authentication
- Cluster health
Skipping these verification steps makes it significantly harder to determine which service introduced a problem.
Advanced Troubleshooting
If the dashboard still displays “Kibana server is not ready yet”, deeper investigation is required.
These techniques can uncover problems that aren’t immediately visible in standard logs.
Enable Debug Logging
Increase the logging level for Wazuh Dashboard temporarily.
Debug logging provides additional details about:
- Plugin initialization
- Authentication
- TLS negotiation
- Saved object migration
- API communication
Remember to return logging to its normal level after troubleshooting to avoid excessive log growth.
Inspect Startup Stack Traces
Review complete stack traces instead of focusing only on the first error message.
Stack traces often reveal:
- Failed JavaScript modules
- Plugin exceptions
- Network failures
- Authentication errors
- Internal server exceptions
The first exception in the stack trace is usually the most useful.
Check Plugin Initialization Errors
Review dashboard logs for plugin-specific failures.
Common examples include:
- Security plugin
- Saved objects
- Index management
- Alerting
- Wazuh application plugin
A single plugin failure can block the entire startup process.
Review OpenSearch Security Logs
The OpenSearch Security plugin maintains its own logs.
Review them for:
- Authentication failures
- Authorization failures
- Certificate validation
- Role mapping errors
- Backend initialization failures
These logs often explain why dashboard authentication is unsuccessful.
Test API Endpoints Directly
Verify backend functionality without relying on the dashboard.
For example:
curl -k -u admin:password https://localhost:9200
A healthy response confirms that:
- The indexer is reachable.
- Authentication succeeds.
- The API is responding normally.
If this request fails, focus on backend services before investigating the dashboard.
Validate Cluster APIs
Use additional cluster APIs to inspect system health.
Useful endpoints include:
/_cluster/health
/_cat/nodes
/_cat/indices
/_cat/shards
/_cluster/allocation/explain
These APIs provide valuable insight into:
- Node availability
- Shard allocation
- Cluster health
- Resource utilization
- Index status
According to the OpenSearch documentation, these diagnostic APIs should be part of every administrator’s troubleshooting workflow.
Common Error Messages and Their Solutions
Below are several errors that frequently accompany the “Kibana server is not ready yet” message.
Understanding them can significantly shorten troubleshooting time.
“No Living Connections”
Cause
The dashboard cannot communicate with Wazuh Indexer.
Common solutions
- Verify the indexer is running.
- Check network connectivity.
- Confirm hostname resolution.
- Verify port 9200 is accessible.
- Review firewall rules.
“Authentication Exception”
Cause
Authentication between the dashboard and indexer failed.
Common solutions
- Verify usernames.
- Verify passwords.
- Check security plugin configuration.
- Confirm role permissions.
- Validate TLS certificates.
“Unable to Retrieve Version Information”
Cause
The dashboard cannot retrieve version information from Wazuh Indexer.
Common solutions
- Verify indexer availability.
- Check API connectivity.
- Review TLS settings.
- Confirm authentication.
“Master Not Discovered”
Cause
The cluster cannot elect or contact a master node.
Common solutions
- Verify node availability.
- Check cluster configuration.
- Review discovery settings.
- Restore failed nodes.
This error is more common in multi-node deployments.
“Cluster Red”
Cause
One or more primary shards are unavailable.
Common solutions
- Identify failed shards.
- Restore missing nodes.
- Free disk space.
- Repair damaged indices.
- Restore from snapshots if necessary.
“Certificate Verification Failed”
Cause
TLS certificate validation failed.
Common solutions
- Replace expired certificates.
- Verify hostname matching.
- Confirm certificate chain.
- Review CA configuration.
- Correct file permissions.
“Index Not Found”
Cause
A required index does not exist or cannot be accessed.
Common solutions
- Verify index names.
- Restore missing indices.
- Rebuild dashboard indices.
- Review migration logs.
- Check permissions.
“Request Timed Out”
Cause
The dashboard did not receive a response before the configured timeout.
Common solutions
- Reduce cluster load.
- Increase available memory.
- Improve storage performance.
- Investigate slow queries.
- Review JVM heap usage.
Troubleshooting Checklist
If you’re short on time, use the following checklist to systematically identify the root cause of the “Kibana server is not ready yet” error in your Wazuh deployment.
Work through each item in order before moving to more advanced troubleshooting.
Confirm Wazuh Dashboard Is Running
Verify that the dashboard service is active.
- Check the service status using
systemctl. - Review recent startup logs.
- Confirm the service remains running after a restart.
Verify Wazuh Indexer Is Healthy
Ensure that Wazuh Indexer is operational.
- Confirm the service is running.
- Verify it is listening on port 9200.
- Review indexer logs for startup or JVM errors.
Check Cluster Health
Inspect the health of your OpenSearch cluster.
- Verify the cluster status is Green or Yellow.
- Investigate any Red cluster state.
- Identify unassigned shards.
- Resolve shard allocation issues before continuing.
Validate Dashboard Configuration
Review the dashboard configuration file.
- Verify indexer hostnames.
- Confirm authentication credentials.
- Validate SSL settings.
- Check certificate paths.
- Review YAML syntax for errors.
Test Network Connectivity
Confirm that the dashboard can communicate with Wazuh Indexer.
- Verify hostname resolution.
- Test connectivity using
curl. - Confirm port 9200 is reachable.
- Review firewall and routing rules.
Verify SSL Certificates
Inspect every certificate used by the deployment.
- Confirm certificates are not expired.
- Verify hostname matching.
- Validate the certificate chain.
- Check certificate file permissions.
Confirm Authentication Credentials
Verify communication between Wazuh Dashboard and Wazuh Indexer.
- Confirm usernames.
- Verify passwords.
- Review role permissions.
- Check OpenSearch Security configuration.
Check Disk Space
Review storage utilization.
- Ensure sufficient free disk space.
- Check OpenSearch disk watermarks.
- Remove unnecessary files if needed.
Verify System Resources
Inspect overall system health.
- Check available memory.
- Monitor CPU utilization.
- Review JVM heap usage.
- Watch for out-of-memory events.
Review Dashboard and Indexer Logs
Logs often reveal the exact cause.
- Dashboard logs
- Indexer logs
- Systemd journal
- Filebeat logs
Focus on the earliest error message rather than secondary failures.
Restart Services in the Proper Order
After making configuration changes, restart services in this sequence:
- Wazuh Indexer
- Wazuh Manager
- Filebeat
- Wazuh Dashboard
Verify each service before proceeding to the next.
Best Practices to Prevent Future Dashboard Startup Issues
While most startup failures can be resolved quickly, preventing them is far preferable.
The following best practices help improve the reliability and stability of production Wazuh deployments.
Monitor Cluster Health Continuously
Configure continuous monitoring for your OpenSearch cluster.
Track:
- Cluster health
- Node availability
- Shard allocation
- Pending tasks
- JVM usage
Detecting degradation early often prevents complete dashboard outages.
Keep Adequate Free Disk Space
Storage shortages are one of the leading causes of unhealthy clusters.
Maintain sufficient free space on:
- OpenSearch data volumes
- Root filesystem
- Log partitions
Set alerts before disk usage reaches critical levels.
Monitor JVM Heap Usage
Regularly monitor Java heap utilization.
Watch for:
- Frequent garbage collection
- High heap utilization
- Out-of-memory exceptions
- Long GC pauses
Proper heap sizing improves both performance and stability.
How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes guide
Renew Certificates Before Expiration
Track certificate expiration dates.
Renew certificates well before they expire to avoid unexpected service interruptions.
Automated certificate monitoring is strongly recommended for production environments.
Perform Regular Backups
Maintain routine backups of:
- Dashboard configuration
- OpenSearch snapshots
- Wazuh configuration files
- Certificates
- Security configuration
Backups greatly simplify recovery from corruption or failed upgrades.
Keep Component Versions Compatible
Upgrade all Wazuh components together whenever possible.
Avoid running mixed versions of:
- Dashboard
- Indexer
- Manager
- Filebeat
Following the official compatibility recommendations reduces the likelihood of startup issues after upgrades.
Implement Centralized Monitoring
Use centralized monitoring tools to observe the health of your Wazuh infrastructure.
Monitor:
- CPU
- Memory
- Disk
- Services
- JVM metrics
- Network connectivity
Early alerting allows administrators to resolve problems before they affect users.
Test Upgrades in Staging
Never deploy major upgrades directly to production.
Instead:
- Test upgrades in a staging environment.
- Validate dashboard functionality.
- Verify plugins.
- Confirm cluster health.
- Review migration logs.
This practice dramatically reduces upgrade-related outages.
According to both the Wazuh and OpenSearch documentation, validating upgrades in non-production environments is one of the safest ways to avoid service interruptions.
Frequently Asked Questions (FAQ)
Question: Why does Wazuh Dashboard display “Kibana server is not ready yet”?
The message indicates that Wazuh Dashboard has started but has not completed its initialization process.
The most common causes include:
- Wazuh Indexer is unavailable.
- Cluster health is red.
- Authentication failures.
- TLS certificate problems.
- Configuration errors.
- Corrupted indices.
- Resource shortages.
The message itself rarely identifies the root cause, so reviewing the logs is essential.
Question: Can Wazuh Dashboard start if Wazuh Indexer is offline?
No.
Wazuh Dashboard depends on Wazuh Indexer for:
- Saved objects
- Dashboards
- Alerts
- Search queries
- Configuration data
If the indexer is offline or unreachable, the dashboard cannot complete its startup sequence.
Question: How do I check if my Wazuh Indexer cluster is healthy?
Use the cluster health API:
curl -k -u admin:password https://localhost:9200/_cluster/health?pretty
A healthy cluster should ideally report Green.
A Yellow status is often acceptable for single-node deployments, while a Red status requires immediate investigation.
Question: Does low disk space cause the “server is not ready yet” error?
Yes.
When available disk space falls below OpenSearch’s configured thresholds, shards may stop allocating and the cluster can enter a degraded state.
As a result, Wazuh Dashboard may remain stuck during startup until sufficient disk space is restored.
Question: Can expired SSL certificates prevent Wazuh Dashboard from starting?
Absolutely.
If certificate validation fails, the dashboard cannot establish a trusted connection with Wazuh Indexer.
Always verify:
- Certificate expiration
- Hostname matching
- Certificate chain
- File permissions
Question: Should I delete indices to fix this problem?
Usually not.
Deleting indices without understanding the underlying issue can permanently remove important data.
Instead:
- Review cluster health.
- Identify the affected index.
- Restore from snapshots if possible.
- Rebuild only the indices that are confirmed to be corrupted.
Deletion should be considered only after backups have been verified.
Question: What logs should I check first?
Start with:
- Wazuh Dashboard logs
- Wazuh Indexer logs
- Systemd journal
- Filebeat logs
The earliest startup error usually points directly to the underlying problem.
Question: What is the correct service restart order?
The recommended restart order is:
- Wazuh Indexer
- Wazuh Manager
- Filebeat
- Wazuh Dashboard
This ensures that backend services are fully operational before the dashboard begins its initialization process.
Conclusion
The “Kibana server is not ready yet” message in a Wazuh deployment almost always indicates that the dashboard is waiting for one or more backend dependencies to become available.
While the error appears generic, the underlying cause is typically one of a handful of issues, including an unavailable Wazuh Indexer, unhealthy cluster state, authentication failures, TLS certificate problems, corrupted indices, insufficient system resources, or version incompatibilities.
The most effective troubleshooting approach is to work through the problem methodically.
Start by confirming that the Wazuh Dashboard and Wazuh Indexer services are running, verify cluster health, validate the dashboard configuration, test connectivity and TLS communication, inspect authentication settings, review available system resources, and carefully examine the dashboard and indexer logs.
By following these steps in sequence, you can usually identify the root cause without making unnecessary configuration changes.
Finally, remember that proactive maintenance is the best long-term solution.
Continuously monitor cluster health, keep sufficient disk space available, track JVM heap usage, renew certificates before they expire, maintain regular backups, and test upgrades in a staging environment before deploying them to production.
These practices will significantly reduce the likelihood of future dashboard startup failures and help keep your Wazuh deployment stable, secure, and available.
For related troubleshooting guides, you may also find these resources helpful:
Be First to Comment