Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

The Wazuh Dashboard is the primary web-based interface used to monitor security events, investigate alerts, manage agents, and analyze data collected throughout a Wazuh deployment.

While the Wazuh Manager handles event processing and the Wazuh Indexer stores security data, the dashboard provides the visibility administrators need to effectively monitor their environment.

When the dashboard fails to load, security teams can lose access to critical information such as active threats, compliance reports, vulnerability assessments, and agent health status.

Dashboard loading issues can appear in several ways. Some administrators encounter a completely blank page, while others receive browser connection errors, SSL warnings, authentication failures, or dashboards that load without displaying any data.

In many cases, the root cause is not the dashboard itself but a problem with one of its dependencies, such as the Wazuh Indexer, Wazuh Manager, network connectivity, or SSL configuration.

Common causes of Wazuh dashboard accessibility problems include:

Stopped or failed dashboard services
Wazuh Indexer connectivity issues
Incorrect dashboard configuration settings
SSL/TLS certificate problems
Firewall or network restrictions
Reverse proxy misconfigurations
Authentication and authorization failures
Browser caching or JavaScript errors

Because the Wazuh Dashboard relies on multiple interconnected components, troubleshooting often requires a systematic approach rather than guessing at potential fixes.

In this guide, you’ll learn how the Wazuh Dashboard works, how to identify the specific symptoms you’re experiencing, and how to diagnose and resolve the most common causes of dashboard loading failures.

By the end, you’ll have a structured troubleshooting process that can quickly restore access to your Wazuh environment.

Understanding How the Wazuh Dashboard Works

Before troubleshooting dashboard loading problems, it’s important to understand how the different Wazuh components interact.

The dashboard itself is only one part of a larger architecture.

A failure anywhere within that architecture can prevent the dashboard from loading correctly.

Wazuh Dashboard Architecture

The Wazuh platform consists of several core components that work together to collect, process, store, and visualize security data.

A typical deployment includes:

Wazuh Dashboard
Wazuh Indexer
Wazuh Manager
Wazuh Agents
Browser clients

When a user opens the dashboard in a browser, requests pass through the dashboard service, which retrieves data from the Wazuh Indexer.

The indexer stores alerts and events generated by the Wazuh Manager, which in turn collects and analyzes data from monitored endpoints.

A failure in any of these communication paths can cause dashboard loading issues.

Wazuh Dashboard

The Wazuh Dashboard provides the graphical user interface used for:

Viewing security alerts
Investigating incidents
Managing agents
Monitoring vulnerabilities
Running compliance reports
Creating visualizations and dashboards

The dashboard is built on top of OpenSearch Dashboards and serves as the frontend layer of the Wazuh platform.

If the dashboard service stops running or becomes misconfigured, users may encounter connection errors, blank screens, or authentication failures.

Wazuh Indexer

The Wazuh Indexer serves as the data storage and search engine for the platform.

Its responsibilities include:

Storing alerts
Managing indexes
Processing search queries
Returning dashboard data
Supporting visualizations and reports

When the dashboard loads, it retrieves nearly all displayed information from the indexer.

If the indexer becomes unavailable, the dashboard may:

Fail to load
Display authentication errors
Show empty dashboards
Generate backend connection errors

Administrators running clustered deployments may find our How to Build a Wazuh Indexer Cluster guide useful for understanding indexer architecture and high availability.

Wazuh Manager

The Wazuh Manager is responsible for collecting, analyzing, and correlating security events.

Its primary functions include:

Agent communication
Log analysis
Rule processing
Vulnerability detection
Active response execution
Alert generation

The manager sends processed alerts to the Wazuh Indexer, where they become available to the dashboard.

If manager services fail or stop forwarding data, the dashboard may continue loading but display little or no information.

Related reading: How to Add Linux Endpoints to Wazuh

Browser and Network Communication

The user’s browser communicates directly with the dashboard server over HTTPS.

This communication depends on:

Network connectivity
Firewall accessibility
Valid SSL certificates
Proper DNS resolution
Open listening ports

Any interruption between the browser and dashboard service can prevent successful page loading.

For example:

Blocked port 443 may cause connection failures.
DNS resolution problems may prevent access entirely.
SSL certificate errors may trigger browser security warnings.

Dashboard Startup Process

Understanding the dashboard startup sequence can help identify where failures occur.

Service Initialization Sequence

When the dashboard starts, it typically follows this process:

Dashboard service starts.
Configuration files are loaded.
SSL certificates are validated.
Authentication providers are initialized.
Connection to the Wazuh Indexer is established.
Plugins are loaded.
Web interface becomes available.

A failure during any stage may prevent the dashboard from loading successfully.

Administrators can monitor startup activity using:

systemctl status wazuh-dashboard
journalctl -u wazuh-dashboard -f

Authentication Flow

When a user accesses the dashboard:

Browser connects to the dashboard service.
Login credentials are submitted.
Dashboard validates credentials.
Authentication request is forwarded to the security backend.
Access permissions are evaluated.
User session is created.

Authentication failures can occur due to:

Incorrect credentials
Expired passwords
Security plugin errors
Indexer authentication issues
Certificate problems

Data Retrieval Process

After authentication succeeds, the dashboard begins requesting data from the Wazuh Indexer.

This process includes:

Querying alert indexes
Loading saved visualizations
Retrieving agent information
Fetching dashboard metrics
Displaying security events

If the dashboard cannot retrieve this information, users may see empty panels, loading errors, or missing visualizations.

Common Failure Points

Several components commonly contribute to dashboard loading issues.

Service Failures

Service-related problems are among the most frequent causes of dashboard outages.

Potential failures include:

Wazuh Dashboard service stopped
Wazuh Indexer service unavailable
Wazuh Manager service failures
Resource exhaustion
Startup errors

Checking service status should always be one of the first troubleshooting steps.

Network Issues

Network connectivity problems can prevent communication between:

Browser and Dashboard
Dashboard and Indexer
Manager and Indexer

Common network-related issues include:

Firewall blocks
Routing problems
DNS failures
Load balancer misconfigurations
Reverse proxy errors

Organizations collecting network security logs can use How to Collect Firewall Logs in Wazuh to help identify blocked traffic affecting dashboard connectivity.

SSL/TLS Problems

Wazuh deployments commonly use encrypted HTTPS communication.

SSL-related issues often include:

Expired certificates
Hostname mismatches
Incorrect certificate chains
Invalid certificate permissions
Self-signed certificate trust issues

The official Wazuh documentation provides detailed guidance on dashboard certificate management.

Configuration Errors

Misconfigurations frequently occur after upgrades, migrations, or manual changes.

Examples include:

Incorrect indexer URLs
Invalid authentication settings
Wrong SSL certificate paths
Reverse proxy mistakes
Corrupted configuration files

According to the official OpenSearch Dashboards documentation, configuration mismatches are one of the most common causes of dashboard startup and connectivity failures.

Properly understanding these architectural components makes it much easier to identify whether a dashboard loading issue originates from the browser, network, dashboard service, indexer, manager, or authentication layer.

Step 1: Verify Wazuh Dashboard Service Status

When the Wazuh Dashboard fails to load, the first step is to confirm that the dashboard service is running properly.

Many dashboard accessibility issues occur because the service has stopped, failed during startup, or encountered a configuration error.

Check Dashboard Service on Linux

Most Wazuh installations running on Linux use systemd to manage services.

Check the current status of the dashboard service:

systemctl status wazuh-dashboard

A healthy service should display output similar to:

Active: active (running)

If the service is inactive, failed, or repeatedly restarting, additional investigation is required before users can access the dashboard.

Pay close attention to:

Service state
Recent error messages
Startup timestamps
Process IDs
Restart attempts

Start the Dashboard Service

If the service is stopped, start it manually:

sudo systemctl start wazuh-dashboard

After starting the service, verify its status again:

systemctl status wazuh-dashboard

If the service immediately stops after starting, review the logs to determine the root cause.

Enable Automatic Startup

To ensure the dashboard automatically starts after system reboots, enable the service:

sudo systemctl enable wazuh-dashboard

You can verify the configuration using:

systemctl is-enabled wazuh-dashboard

Expected output:

enabled

Failing to enable automatic startup can result in dashboard outages after maintenance windows, upgrades, or unexpected server restarts.

Review Dashboard Service Logs

Service logs often contain the exact reason why the dashboard is failing.

Monitor logs in real time:

journalctl -u wazuh-dashboard -f

For historical logs:

journalctl -u wazuh-dashboard

The logs can reveal:

Configuration errors
Authentication problems
SSL certificate issues
Indexer connectivity failures
Plugin initialization errors

The official Wazuh documentation recommends checking service logs as one of the first troubleshooting steps when diagnosing dashboard startup issues.

Identify Startup Errors

Once you’ve reviewed the logs, focus on identifying the specific error preventing the dashboard from starting successfully.

Service Crashes

Repeated service crashes often indicate:

Corrupted configuration files
Insufficient system resources
Failed plugin initialization
Dependency issues

Common log entries include:

FATAL Error
Process exited unexpectedly
Service failed to start

If the dashboard recently stopped working after an upgrade, verify that all Wazuh components are running compatible versions.

Permission Issues

Permission-related errors can prevent the dashboard from accessing:

Configuration files
SSL certificates
Log files
Temporary directories

Examples include:

Permission denied
Access forbidden
Unable to read file

Verify file ownership and permissions:

ls -la /etc/wazuh-dashboard/

Configuration Loading Failures

Configuration syntax errors frequently prevent successful startup.

Common issues include:

Invalid YAML formatting
Missing configuration values
Incorrect file paths
Typographical errors

If you’ve recently modified dashboard settings, carefully review:

/etc/wazuh-dashboard/opensearch_dashboards.yml

For certificate-related startup failures, see How to Fix Wazuh Certificate Errors.

Step 2: Confirm Dashboard Port Accessibility

Even if the dashboard service is running, users will not be able to access it if the listening port is unavailable or blocked.

Verify Listening Ports

Check whether the dashboard is actively listening for incoming connections.

Run:

ss -tulpn | grep 5601

You may also use:

netstat -tulpn | grep 5601

A healthy result should show a process bound to the configured dashboard port.

Example:

LISTEN 0 128 *:5601 *:*

If no listening port appears, the dashboard service may not have started successfully.

Test Local Connectivity

Once you’ve confirmed the service is listening, test connectivity from the dashboard server itself.

Run:

curl -k https://localhost:5601

A successful response indicates that:

The dashboard service is operational
The port is reachable locally
SSL communication is functioning

Errors such as:

Connection refused
Connection timed out

typically indicate service or networking problems.

Test Remote Connectivity

After confirming local access, verify that remote clients can reach the dashboard.

Browser Testing

Open a browser and navigate to:

https://your-dashboard-server

https://your-server-ip:5601

Observe any errors presented by the browser.

Examples include:

ERR_CONNECTION_REFUSED
ERR_CONNECTION_TIMED_OUT
SSL certificate warnings
Authentication failures

Network Validation

Test connectivity from another system.

Examples:

ping dashboard-server

telnet dashboard-server 5601

nc -zv dashboard-server 5601

Successful tests confirm that network routing is functioning properly.

Firewall Verification

Firewall rules frequently block dashboard access.

Verify firewall settings on:

Linux firewall
Cloud security groups
Network firewalls
Reverse proxies

Examples:

firewall-cmd --list-all

ufw status

If you’re monitoring firewall activity with Wazuh, see How to Collect Firewall Logs in Wazuh for additional visibility into blocked connections.

Check Reverse Proxy Configurations

Many organizations deploy the Wazuh Dashboard behind a reverse proxy.

Misconfigured proxies are a common cause of dashboard loading failures.

Nginx Setup

A typical Nginx configuration forwards requests to the dashboard service.

Example:

location / {
    proxy_pass https://localhost:5601;
}

Common problems include:

Incorrect proxy_pass values
Missing SSL settings
WebSocket forwarding issues
Invalid upstream definitions

Apache Setup

Apache deployments may use:

ProxyPass /
ProxyPassReverse /

Errors in proxy configuration can prevent requests from reaching the dashboard backend.

Common symptoms include:

Blank pages
Gateway errors
Login page failures
Authentication loops

Proxy Forwarding Issues

Review proxy logs for:

502 Bad Gateway errors
504 Gateway Timeout errors
SSL handshake failures
Backend connection errors

The official Nginx documentation recommends verifying upstream connectivity whenever reverse-proxied applications become inaccessible.

Step 3: Verify Connectivity Between Dashboard and Wazuh Indexer

The Wazuh Dashboard depends heavily on the Wazuh Indexer.

Even if the dashboard service itself is running correctly, users may still experience loading failures if the dashboard cannot communicate with the indexer.

Check Indexer Status

Start by verifying that the indexer service is running.

systemctl status wazuh-indexer

A healthy system should display:

Active: active (running)

If the indexer is stopped, start it:

sudo systemctl start wazuh-indexer

Then confirm its status again.

Administrators managing clustered deployments should also verify that all cluster nodes are healthy.

Test Indexer API Access

Next, verify that the indexer’s API is accessible.

Run:

curl -k -u admin:password https://localhost:9200

A healthy response typically returns cluster information similar to:

{
  "name": "node-1",
  "cluster_name": "wazuh-cluster"
}

If the command fails, investigate:

Service availability
Authentication configuration
TLS certificates
Network connectivity

You can also check cluster health:

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

A healthy cluster generally reports:

"status": "green"

or:

"status": "yellow"

Verify Dashboard Configuration

The dashboard must be configured with the correct indexer connection details.

Review the primary dashboard configuration file:

/etc/wazuh-dashboard/opensearch_dashboards.yml

Important settings include:

opensearch.hosts:
server.host:
server.ssl.enabled:

Verify that:

Hostnames are correct
Ports are correct
SSL settings match the indexer configuration
Credentials are valid

Even a small configuration mismatch can prevent successful communication.

Common Indexer Connection Problems

Several recurring issues prevent the dashboard from connecting to the Wazuh Indexer.

Incorrect Hostname

If the configured hostname cannot be resolved, the dashboard will fail to establish a connection.

Examples include:

Typographical errors
Invalid DNS records
Outdated IP addresses

Test hostname resolution:

nslookup indexer-hostname

Wrong Credentials

Authentication failures are another common cause.

Look for log entries such as:

Authentication failed
Unauthorized
Forbidden

Verify:

Username
Password
Role mappings
Security configuration

SSL Verification Failures

TLS certificate mismatches frequently break dashboard-to-indexer communication.

Common examples include:

Expired certificates
Incorrect hostnames
Invalid certificate chains
Missing certificate authorities

Network Connectivity Issues

Finally, ensure the dashboard server can reach the indexer server over the required port.

Test connectivity:

ping indexer-server

telnet indexer-server 9200

nc -zv indexer-server 9200

If connectivity fails, investigate:

Firewall rules
Security groups
Routing issues
VPN configurations
Reverse proxy restrictions

Resolving dashboard-to-indexer communication issues often restores dashboard functionality immediately, making this one of the highest-priority troubleshooting steps when diagnosing Wazuh dashboard loading problems.

Step 4: Check Wazuh Manager Health

The Wazuh Manager is responsible for collecting, analyzing, and forwarding security events to the Wazuh Indexer.

If the manager is unhealthy, the dashboard may load successfully but display incomplete, outdated, or entirely missing data.

Even when the dashboard and indexer are functioning correctly, manager-related problems can significantly impact dashboard visibility.

Verify Manager Service Status

Start by confirming that the Wazuh Manager service is running.

systemctl status wazuh-manager

A healthy system should report:

Active: active (running)

If the service is stopped, start it:

sudo systemctl start wazuh-manager

To ensure the service starts automatically after reboot:

sudo systemctl enable wazuh-manager

If the manager repeatedly fails to start, investigate log files for configuration or dependency errors.

Confirm Agent Connectivity

The dashboard relies on data received from Wazuh agents.

If agents are disconnected, dashboards may appear empty or show stale information.

List all registered agents:

/var/ossec/bin/agent_control -l

Example output:

ID: 001, Name: web-server, IP: 10.0.0.10, Active
ID: 002, Name: db-server, IP: 10.0.0.20, Active

Pay attention to:

Active agents
Disconnected agents
Never-connected agents
Recently disconnected systems

A large number of disconnected agents may indicate:

Network communication problems
Firewall restrictions
Agent configuration issues
Manager service interruptions

For agent-specific troubleshooting, see Wazuh Agent Not Connecting to Manager? 12 Proven Fixes.

Review Manager Logs

Manager logs provide valuable insight into processing and communication problems.

Monitor logs in real time:

tail -f /var/ossec/logs/ossec.log

Review recent activity for:

Agent connection failures
Decoder errors
Rule processing failures
Indexer communication issues
Queue overload warnings

You can also search for critical errors:

grep -i error /var/ossec/logs/ossec.log

and:

grep -i warning /var/ossec/logs/ossec.log

The official Wazuh documentation recommends reviewing manager logs whenever dashboard data appears incomplete or outdated.

Manager Issues That Affect Dashboard Visibility

Several manager-related problems can directly impact what appears in the dashboard.

Agent Communication Failures

If agents cannot communicate with the manager, new events stop flowing into the platform.

Common causes include:

Firewall blocks
Network outages
Agent authentication issues
Incorrect manager addresses

Symptoms often include:

Missing endpoint data
Inactive agents
Empty dashboards
Stale alerts

Analysis Daemon Issues

The analysis daemon is responsible for processing incoming events.

If it becomes overloaded or fails, alerts may not be generated properly.

Potential indicators include:

Processing delays
Missing alerts
Event backlogs
High CPU utilization

Administrators using custom rules should also verify rule behavior.

Log Processing Interruptions

Wazuh relies on continuous log ingestion to generate dashboard content.

Interruptions can occur because of:

Decoder failures
Corrupted log sources
Misconfigured integrations
Queue congestion

If log processing stops, dashboards may appear operational while displaying little or no current security data.

Step 5: Troubleshoot SSL and Certificate Errors

SSL and certificate problems are among the most common causes of dashboard loading failures.

Since Wazuh uses encrypted communication between components, even a minor certificate issue can prevent successful authentication or data retrieval.

Common SSL-Related Symptoms

SSL problems often present themselves through browser warnings, connection failures, or authentication errors.

Browser Certificate Warnings

Users may encounter errors such as:

NET::ERR_CERT_AUTHORITY_INVALID
NET::ERR_CERT_COMMON_NAME_INVALID
NET::ERR_CERT_DATE_INVALID

These warnings indicate that the browser does not trust the certificate or has detected a configuration issue.

Common causes include:

Self-signed certificates
Expired certificates
Hostname mismatches
Incomplete certificate chains

Secure Connection Failures

In some cases, the browser cannot establish an encrypted connection at all.

Examples include:

This site can't provide a secure connection
SSL_ERROR_HANDSHAKE_FAILURE_ALERT
ERR_SSL_PROTOCOL_ERROR

These errors typically indicate:

TLS configuration problems
Invalid certificates
Unsupported cipher suites
SSL handshake failures

Authentication Issues

SSL problems can also interfere with backend authentication.

Symptoms may include:

Login failures
Session creation errors
Dashboard startup failures
Indexer connection errors

Because authentication relies heavily on secure communication, certificate problems often affect multiple components simultaneously.

Validate Certificate Configuration

The next step is verifying that certificates are configured correctly throughout the environment.

Certificate File Locations

Verify that certificate paths referenced in configuration files actually exist.

Examples:

ls -la /etc/wazuh-dashboard/certs/

Confirm the presence of:

Server certificates
Private keys
Certificate authority files

Missing files will typically prevent dashboard startup.

Certificate Permissions

Incorrect permissions can prevent services from reading certificate files.

Review ownership and permissions:

ls -l /etc/wazuh-dashboard/certs/

Typical problems include:

Root-only access
Incorrect group ownership
Missing read permissions

Certificate Expiration Dates

Expired certificates are a common source of SSL failures.

Check expiration information:

openssl x509 -in dashboard.pem -text -noout

Look for:

Not Before:
Not After:

If the certificate has expired, it must be replaced or renewed.

According to the recommendations published by the National Institute of Standards and Technology, certificate lifecycle management is essential for maintaining secure administrative systems.

Check Dashboard SSL Settings

The dashboard configuration must reference the correct certificates and keys.

Typical settings include:

server.ssl.enabled: true

server.ssl.certificate: /etc/wazuh-dashboard/certs/dashboard.pem

server.ssl.key: /etc/wazuh-dashboard/certs/dashboard-key.pem

Verify:

File paths are correct
Certificates exist
Keys match certificates
Permissions are appropriate

Even a single incorrect path can prevent successful startup.

Regenerate Certificates if Necessary

If certificates are corrupted, expired, or incorrectly configured, regeneration may be required.

Certificate Recreation Process

The exact process depends on the deployment method, but typically includes:

Generate new certificates.
Update configuration files.
Distribute certificates to affected services.
Verify trust relationships.
Test secure connectivity.

For a complete certificate troubleshooting guide, see How to Fix Wazuh Certificate Errors.

Service Restart Requirements

After updating certificates, restart affected services:

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

Then verify that all services start successfully and can communicate securely.

Step 6: Review Dashboard Configuration Files

Misconfigured dashboard settings frequently cause startup failures, authentication problems, and indexer connectivity issues.

Even a small typo in the configuration file can prevent the dashboard from loading.

Main Dashboard Configuration File

The primary dashboard configuration file is located at:

/etc/wazuh-dashboard/opensearch_dashboards.yml

Most dashboard-related settings are defined here.

Before making changes, create a backup:

cp /etc/wazuh-dashboard/opensearch_dashboards.yml \
/etc/wazuh-dashboard/opensearch_dashboards.yml.bak

This allows you to quickly restore a working configuration if needed.

Important Settings to Verify

Several configuration parameters are especially important when troubleshooting dashboard loading issues.

Server Host

The dashboard must listen on the appropriate network interface.

Example:

server.host: 0.0.0.0

This configuration allows connections from any network interface.

Common alternatives include:

server.host: localhost

or:

server.host: 192.168.1.10

An incorrect value may prevent remote users from accessing the dashboard.

Indexer Hosts

The dashboard must know how to reach the Wazuh Indexer.

Example:

opensearch.hosts:
  - https://127.0.0.1:9200

Verify:

Hostnames
IP addresses
Ports
Protocols

If the dashboard cannot connect to the specified indexer host, loading failures are likely.

SSL Certificate Paths

Certificate locations must be accurate.

Certificate Configuration

Example:

server.ssl.certificate: /etc/wazuh-dashboard/certs/dashboard.pem

Verify that:

File exists
Path is correct
Certificate is valid

Key Configuration

Example:

server.ssl.key: /etc/wazuh-dashboard/certs/dashboard-key.pem

Ensure:

Key file exists
Permissions are correct
Certificate and key match

Common Configuration Mistakes

Several recurring configuration problems cause dashboard startup and connectivity failures.

Syntax Errors

The dashboard configuration file uses YAML formatting.

Common mistakes include:

Missing colons
Incorrect indentation
Extra spaces
Invalid characters

Syntax errors often prevent the service from starting.

Incorrect File Paths

Misconfigured paths can prevent access to:

SSL certificates
Private keys
Authentication files
Plugin resources

Always verify file existence before restarting services.

Wrong IP Addresses

Incorrect addresses frequently occur after:

Server migrations
Infrastructure changes
DNS modifications
Network redesigns

Verify that configured hosts match the actual deployment.

Invalid Credentials

Authentication settings must align with the Wazuh Indexer configuration.

Incorrect credentials often generate errors such as:

Authentication failed
Unauthorized
Forbidden

The official OpenSearch documentation notes that authentication and endpoint configuration mismatches are among the most common causes of dashboard connectivity failures.

Once configuration settings have been validated, the next step is examining browser-side issues, JavaScript errors, and system resource limitations that may prevent the dashboard from loading properly despite healthy backend services.

Step 7: Analyze Dashboard Log Files

When the Wazuh Dashboard fails to load, logs are one of the most reliable sources of truth.

They provide direct insight into service-level failures, configuration issues, authentication problems, and backend connectivity errors.

Unlike browser symptoms, logs reveal the exact point of failure inside the system.

Dashboard Log Locations

The primary method for viewing Wazuh Dashboard logs on Linux systems is through systemd journal logs.

View live logs:

journalctl -u wazuh-dashboard -f

View historical logs:

journalctl -u wazuh-dashboard

For filtered output:

journalctl -u wazuh-dashboard | grep -i error

Depending on your installation, additional log files may exist under:

/var/log/wazuh-dashboard/

or:

/usr/share/wazuh-dashboard/logs/

Log analysis should be performed immediately after reproducing the issue to capture relevant error events.

Errors to Look For

Wazuh Dashboard logs typically expose failures in four major categories: authentication, SSL, connectivity, and plugin initialization.

Authentication Exceptions

Authentication-related errors indicate that the dashboard cannot validate user credentials or communicate with the authentication backend.

Common log entries include:

Authentication failed
Unauthorized
Forbidden
Invalid credentials

These issues are often caused by:

Incorrect username or password
Broken role mappings
Indexer security plugin misconfiguration
Expired sessions or tokens

SSL Exceptions

SSL-related errors are among the most common causes of dashboard startup failures.

Typical log entries:

SSL Handshake failed
Certificate validation error
Unable to verify certificate chain

These errors generally indicate:

Expired certificates
Hostname mismatches
Missing CA certificates
Incorrect TLS configuration

Connection Timeout Errors

Timeout errors indicate that the dashboard cannot reach dependent services, especially the Wazuh Indexer or backend APIs.

Common logs:

Request timeout
Connection refused
No response from server

Root causes include:

Network outages
Firewall restrictions
Indexer service downtime
DNS resolution failures

These issues often require validating network paths between components.

Plugin Loading Failures

The Wazuh Dashboard depends on multiple plugins for visualization and security functionality.

If plugins fail to load, the dashboard may become unusable or fail to render.

Common errors include:

Plugin initialization failed
Missing dependency
Cannot load module

Typical causes:

Corrupted installation
Version mismatch between components
Incomplete upgrades
Missing package dependencies

In severe cases, reinstalling the dashboard package may be required.

Step 8: Check System Resources

System resource limitations are a frequently overlooked cause of Wazuh Dashboard failures.

If the server is under heavy load or running out of memory or disk space, the dashboard may fail to start, load slowly, or become completely unresponsive.

Verify Available Memory

Check current memory usage:

free -h

Key metrics to observe:

Total memory
Used memory
Available memory
Swap usage

Low available memory can cause:

Dashboard crashes
Slow loading times
Indexer communication failures
Service instability

If memory usage is consistently high, consider increasing system RAM or optimizing Wazuh workloads.

Check CPU Utilization

High CPU usage can prevent dashboard services from responding in a timely manner.

Monitor CPU usage:

top

or:

htop

Look for:

Wazuh Dashboard process spikes
Wazuh Indexer CPU saturation
System-wide load averages

Sustained CPU saturation may lead to:

Dashboard timeouts
API request failures
Slow rendering of visualizations

Verify Disk Space

Disk exhaustion is one of the most critical failure conditions for Wazuh deployments.

Check disk usage:

df -h

Pay attention to:

Root filesystem usage
/var partition usage
Log storage directories

If disk space is full or near capacity:

Logs may stop writing
Indexer may fail to create indexes
Dashboard may fail to start

Resource-Related Dashboard Problems

System resource constraints can directly affect dashboard availability and performance.

Out-of-Memory Conditions

When memory is exhausted, Linux may terminate processes using the OOM killer.

Symptoms include:

Sudden dashboard shutdowns
Service restarts
Kernel OOM logs

Check system logs:

dmesg | grep -i oom

Disk Exhaustion

When disk space is fully consumed:

Indexer stops writing data
Dashboard fails to load visualizations
Log files stop updating

This condition is often misdiagnosed as a service failure when it is actually a storage issue.

High CPU Utilization

Sustained CPU pressure can degrade dashboard responsiveness significantly.

Typical effects include:

Slow UI rendering
Delayed login response
Partial dashboard loading
Timeout errors

Optimizing resource allocation or scaling infrastructure may be required in high-load environments.

Step 9: Troubleshoot Browser-Related Issues

Not all Wazuh Dashboard loading issues originate from the server.

In many cases, the problem is isolated to the user’s browser environment, including cached files, extensions, or JavaScript execution failures.

Clear Browser Cache

Cached assets can become outdated after upgrades or configuration changes.

Problems caused by cache include:

Blank dashboard screens
Broken UI components
JavaScript errors
Stale login sessions

To resolve:

Clear browser cache and cookies
Refresh page with hard reload (Ctrl + Shift + R)

This ensures the browser loads the latest dashboard assets.

Test Using Incognito Mode

Incognito or private browsing mode disables most extensions and uses a clean session.

This helps identify:

Extension conflicts
Corrupted session data
Authentication token issues

If the dashboard loads correctly in incognito mode, the issue is likely browser-specific rather than server-side.

Try a Different Browser

Browser compatibility issues can also prevent proper rendering.

Test across:

Google Chrome
Mozilla Firefox
Microsoft Edge

Failures in only one browser usually indicate:

Rendering incompatibility
Extension interference
Local browser corruption

Review Browser Developer Console

The browser developer console is essential for diagnosing frontend errors.

Open it using:

Chrome/Edge: F12 → Console tab
Firefox: F12 → Console tab

Look for:

JavaScript Errors

Examples:

Uncaught TypeError
Failed to load script
Unexpected token

These errors often indicate:

Missing dashboard assets
Corrupted frontend build
Reverse proxy misconfiguration

Network Request Failures

Check the Network tab for failed API calls such as:

401 Unauthorized
403 Forbidden
500 Internal Server Error
Failed to load resource

These errors often indicate backend or authentication issues rather than browser problems.

At this stage, if the dashboard still does not load correctly, the issue is typically rooted in backend services (Indexer, Manager), SSL configuration, or infrastructure-level networking constraints.

The next step is consolidating findings into a structured root-cause analysis and applying targeted remediation based on the failing layer.

Step 10: Restart the Entire Wazuh Stack

When isolated troubleshooting steps do not resolve a “Wazuh dashboard not loading” issue, restarting the full Wazuh stack can help reinitialize service dependencies, clear transient faults, and restore proper communication between components.

This step is particularly useful after configuration changes, certificate updates, or partial service failures.

A full restart should always be performed in a controlled order to avoid dependency conflicts between the Wazuh Manager, Indexer, and Dashboard.

Restart Wazuh Manager

The Wazuh Manager should be restarted first to ensure that event processing and agent communication services are properly reinitialized.

systemctl restart wazuh-manager

After restarting, verify its status:

systemctl status wazuh-manager

Look for:

Active (running) state
No repeated restart loops
Absence of critical errors in logs

If issues persist, inspect:

journalctl -u wazuh-manager -f

Restart Wazuh Indexer

The Wazuh Indexer is responsible for storing and serving all security events to the dashboard.

Restarting it helps resolve cluster inconsistencies, index corruption issues, or failed shard allocations.

systemctl restart wazuh-indexer

Verify service health:

systemctl status wazuh-indexer

Confirm cluster readiness:

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

Expected states:

green → fully healthy
yellow → degraded but functional
red → critical failure (requires immediate attention)

If the cluster does not recover, review indexer logs for startup or shard allocation issues.

Restart Wazuh Dashboard

Finally, restart the dashboard service to re-establish connections with the manager and indexer.

systemctl restart wazuh-dashboard

Verify status:

systemctl status wazuh-dashboard

Then confirm log output:

journalctl -u wazuh-dashboard -f

Watch for:

Successful plugin initialization
Indexer connection establishment
Authentication service startup
Absence of SSL or configuration errors

Validate Service Health After Restart

Once all services have been restarted, a structured validation process ensures the system is fully operational.

Service Status Checks

Confirm all core services are running:

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

All services should show:

Active (running)
No repeated restart failures
Stable uptime

Log Verification

Check logs for each component to confirm clean startup behavior.

Manager logs:

journalctl -u wazuh-manager | tail -n 50

Indexer logs:

journalctl -u wazuh-indexer | tail -n 50

Dashboard logs:

journalctl -u wazuh-dashboard | tail -n 50

Look for absence of:

Fatal errors
Authentication failures
SSL handshake errors
Plugin initialization failures

Dashboard Accessibility Testing

Finally, confirm that the dashboard is accessible from both local and remote environments.

Test locally:

curl -k https://localhost:5601

Test remotely:

Open browser access
Verify login page loads correctly
Confirm dashboards render data properly

If the dashboard still fails after a full stack restart, the issue is likely related to configuration corruption, certificate mismatch, or deep infrastructure-level networking constraints.

Advanced Troubleshooting Scenarios

Some Wazuh dashboard issues persist even after basic and intermediate troubleshooting.

These scenarios typically involve performance bottlenecks, misconfigured infrastructure, or deeper system-level constraints.

Dashboard Loads Extremely Slowly

A slow-loading dashboard is usually a symptom of backend inefficiencies rather than a complete failure.

Resource Bottlenecks

High memory or CPU usage on any Wazuh component can significantly degrade performance.

Large Index Sizes

Excessively large indexes can slow query responses from the Wazuh Indexer, causing delays in dashboard rendering.

Cluster Health Issues

A degraded cluster state (yellow or red) can cause delayed or incomplete data retrieval.

Related internal reading: How to Build a Wazuh Indexer Cluster

Dashboard Works Locally but Not Remotely

When the dashboard is accessible only from the host machine, the issue is typically network-related.

Firewall Restrictions

Inbound traffic may be blocked on required ports such as 5601 or 443.

Network ACLs

Cloud or enterprise network policies may restrict external access.

Reverse Proxy Misconfigurations

Incorrect proxy rules can prevent external requests from reaching the dashboard service.

Dashboard Shows “Server Not Ready Yet”

This message indicates that the dashboard is still waiting for backend services to initialize.

Indexer Startup Delays

The indexer may take longer to initialize large datasets or recover shards.

Cluster Health Problems

If the cluster is not in a green state, the dashboard may delay startup.

Initialization Failures

Plugin or authentication initialization errors can block full dashboard availability.

Dashboard Crashes Repeatedly

Repeated crashes indicate a deeper systemic issue that must be addressed at the configuration or resource level.

Corrupted Configuration

Invalid or malformed configuration files can cause continuous restart loops.

Plugin Issues

Incompatible or corrupted plugins may prevent successful startup.

Resource Exhaustion

Insufficient memory or disk space can cause the operating system to terminate processes unexpectedly.

If crashes persist, a clean reinstall or configuration rollback may be required.

Preventing Future Dashboard Outages

Once the Wazuh Dashboard is restored, implementing preventative measures ensures long-term stability and reduces the likelihood of future outages.

Monitor Service Availability

Continuous monitoring helps detect issues before they impact users.

Implement:

Service health checks
Uptime monitoring
Alerting on service failures
Log-based anomaly detection

Maintain System Resources

Proper resource planning is essential for stable Wazuh operations.

Focus on:

CPU capacity planning
Memory allocation
Disk storage monitoring
Index growth tracking

Keep Wazuh Updated

Running supported versions ensures compatibility and security.

Benefits include:

Bug fixes
Performance improvements
Security patches
Improved stability across components

Back Up Configuration Files

Regular backups reduce recovery time during failures.

Key files to back up:

/etc/wazuh-dashboard/opensearch_dashboards.yml
Indexer configuration files
Manager configuration files
SSL certificates and keys

Regularly Review Logs

Proactive log analysis helps identify issues before they escalate.

Recommended practices:

Scheduled log reviews
Automated alerting for errors
Trend analysis for recurring issues
Monitoring authentication and SSL events

By combining proactive monitoring, proper configuration management, and structured troubleshooting procedures, administrators can significantly reduce the risk of future Wazuh Dashboard outages and ensure consistent system visibility.

Frequently Asked Questions

This section addresses the most common questions that arise when troubleshooting a “Wazuh dashboard not loading” issue.

Each answer focuses on practical validation steps and the most likely root causes.

Question: Why is my Wazuh Dashboard showing a blank page?

A blank page typically indicates a frontend rendering failure or a backend communication issue.

Common causes include:

JavaScript errors in the browser
Corrupted or outdated cached files
Dashboard service not fully initialized
Reverse proxy misconfiguration
Failed plugin loading during startup

To isolate the issue:

Check browser developer console (F12 → Console)
Restart the dashboard service
Clear browser cache
Verify Wazuh Dashboard logs

Question: How do I restart the Wazuh Dashboard service?

Restart the service using systemd:

systemctl restart wazuh-dashboard

Then verify its status:

systemctl status wazuh-dashboard

If the service fails to restart, immediately review logs:

journalctl -u wazuh-dashboard -f

Question: What port does Wazuh Dashboard use by default?

By default, the Wazuh Dashboard typically uses:

5601 (default OpenSearch Dashboards port)

However, deployments may vary depending on configuration or reverse proxy usage. Some environments expose the dashboard through:

443 (HTTPS via reverse proxy)

To confirm the active port:

ss -tulpn | grep wazuh

Question: Why does the login page load but reject valid credentials?

This issue usually indicates a backend authentication or indexer communication problem rather than a simple credential issue.

Common causes include:

Wazuh Indexer authentication failure
Incorrect role mappings
Expired or invalid sessions
SSL certificate mismatches
Corrupted security plugin configuration

Validation steps:

Check indexer connectivity
Review dashboard logs
Confirm user roles and permissions

Question: How can I verify that the Wazuh Indexer is working?

You can verify indexer health using:

systemctl status wazuh-indexer

Then test API responsiveness:

curl -k -u admin:password https://localhost:9200

A healthy response should return cluster metadata.

You can also check cluster health:

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

A “green” or “yellow” status indicates a functional cluster.

Question: What causes the “Server Not Ready Yet” error?

This message indicates that the dashboard is still waiting for backend services to fully initialize.

Common causes include:

Wazuh Indexer still starting up
Cluster health not yet stable
Plugin initialization delays
Authentication services not ready
Resource constraints slowing startup

In most cases, waiting a few minutes after startup resolves the issue. If it persists, check service logs.

Question: Can firewall rules prevent the dashboard from loading?

Yes. Firewall restrictions are a common cause of dashboard accessibility failures.

They can block:

Dashboard port (5601 or 443)
Indexer communication (9200)
Manager communication channels

Symptoms include:

ERR_CONNECTION_TIMED_OUT
ERR_CONNECTION_REFUSED
Blank or unreachable dashboard

Check firewall rules using:

ufw status
firewall-cmd --list-all

Question: How do I check Wazuh Dashboard logs?

Use systemd journal logs:

journalctl -u wazuh-dashboard -f

For historical logs:

journalctl -u wazuh-dashboard

To filter errors:

journalctl -u wazuh-dashboard | grep -i error

Logs are essential for diagnosing:

Startup failures
Authentication errors
SSL issues
Plugin loading problems

Conclusion

The Wazuh Dashboard is a central component of the Wazuh security platform, and when it fails to load, it can significantly impact visibility into security events, alerts, and system health.

Recap of the most common dashboard loading issues

Most “Wazuh dashboard not loading” problems fall into a few core categories:

Service failures (dashboard, indexer, or manager not running)
Network or firewall restrictions
SSL/TLS certificate errors
Misconfigured dashboard or indexer settings
Browser-related caching or JavaScript issues
Resource exhaustion (CPU, memory, disk)

Importance of checking services, connectivity, SSL, and configurations systematically

Effective troubleshooting requires a structured approach rather than random checks.

The most reliable method is to validate:

Services – Ensure all Wazuh components are running
Connectivity – Verify dashboard-to-indexer and manager communication
SSL/TLS – Confirm certificates are valid and trusted
Configuration – Review dashboard and indexer configuration files

This layered approach helps isolate the exact failure point quickly.

Recommended troubleshooting workflow

A practical workflow for resolving dashboard issues:

Check dashboard service status
Verify ports and network access
Validate indexer and manager health
Review SSL certificates
Inspect configuration files
Analyze logs for errors
Test browser behavior
Restart full Wazuh stack if needed

Final tips for maintaining a stable Wazuh deployment

To reduce future dashboard outages:

Monitor all Wazuh services continuously
Maintain sufficient CPU, memory, and disk resources
Keep Wazuh components updated and version-aligned
Regularly review logs for early warning signs
Backup configuration files and certificates
Validate cluster health in multi-node deployments

A stable Wazuh environment depends on both proactive monitoring and disciplined configuration management.

Consistent maintenance ensures that dashboard availability remains reliable and that security visibility is never interrupted.