Troubleshooting “No Matching Indices Found” Error in Wazuh Dashboard

The “No Matching Indices Found” error in the Wazuh Dashboard occurs when OpenSearch Dashboards cannot resolve any data source that matches the configured index pattern (typically wazuh-alerts-* or related patterns).

In practical terms, the dashboard is querying for security telemetry data, but the underlying index pattern does not match any existing indices in OpenSearch.

This issue is tightly coupled to how index patterns (data views) are defined and mapped in OpenSearch Dashboards.

If the pattern is incorrect, missing, or points to a non-existent dataset, the dashboard will render empty states or warnings instead of security events.

You typically observe:

• Empty Wazuh dashboards with no visualizations populated
• Missing alerts, rules, or agent activity data
• “No indices match pattern” warnings in saved visualizations
• Partial UI loading where widgets fail silently

At its core, this is not a Wazuh “application bug” but a data layer mismatch between Wazuh indices and OpenSearch Dashboards configuration.

Common Causes of the Error

This error is almost always caused by a breakdown in one or more parts of the Wazuh → OpenSearch → Dashboard pipeline.

Missing or deleted indices in OpenSearch

If Wazuh is not generating or retaining indices (e.g., wazuh-alerts-*), the dashboard has nothing to query.

This can happen due to:

• Disk pressure leading to index deletion
• Improper retention configuration
• Cluster reset or snapshot restore issues

Incorrect index pattern configuration in Wazuh dashboards

A very common issue is a mismatched or outdated index pattern such as:

• wazuh-alert-* (incorrect)
• wazuh-alerts-* (correct)

Even a minor typo will break dashboard queries.

Delayed or failed data ingestion from Wazuh manager

If the Wazuh manager is not forwarding logs properly, indices will not be created in OpenSearch.

Causes include:

• Agent disconnections
• Log pipeline congestion
• Filebeat/Wazuh-indexer communication issues

Version mismatch after upgrade

Upgrades between:

• Wazuh Manager
• Wazuh Indexer (OpenSearch fork)
• Wazuh Dashboard

can lead to incompatible index templates or renamed fields, breaking index resolution.

Permissions or security plugin misconfiguration

If the authenticated user lacks permissions to read indices, OpenSearch Dashboards may behave as though indices do not exist.

Corrupted or missing .kibana / dashboard metadata indices

The .kibana (or OpenSearch Dashboards system index) stores saved objects and index patterns. If corrupted, dashboards fail to resolve correct mappings.

Step-by-Step Diagnosis

 Verify Existing Indices in OpenSearch

Start by confirming whether Wazuh indices actually exist in the cluster.

Run:

_cat/indices?v

You should look specifically for:

• wazuh-alerts-*
• wazuh-archives-*

If these are missing entirely, the issue is upstream (data ingestion or manager-side problem), not the dashboard.

Validate Index Patterns in Wazuh Dashboard

Next, confirm that OpenSearch Dashboards is using the correct data view:

• Navigate to Stack Management → Index Patterns
• Ensure pattern exists:
  wazuh-alerts-*

Also verify:

• Time filter range is not restricting results (e.g., “Last 15 minutes” hiding older logs)
• Default time field is correctly set (usually @timestamp)

A misconfigured time filter is one of the most overlooked causes of “empty dashboard” symptoms.

Confirm Wazuh Manager Data Flow

At this stage, validate whether data is actually flowing into the indexer:

• Check agent connectivity status (active/disconnected)
• Confirm logs are being received by the manager
• Inspect ingestion queues for backlog or drops

If no new indices are being created, the issue is likely:

• Agent communication failure
• Wazuh manager misconfiguration
• Indexer pipeline bottleneck

If you’re already working with agent ingestion issues, this guide may help:

How to Add Linux Endpoints to Wazuh

Inspect OpenSearch Dashboards Saved Objects

If indices exist but dashboards still fail, the issue may lie in saved objects.

Check:

• Missing or corrupted index patterns in .kibana or OpenSearch Dashboards system index
• Broken saved visualizations referencing outdated index names
• Cluster health issues affecting metadata storage

A corrupted saved object layer often appears after:

• Failed upgrades
• Interrupted migrations
• Version mismatches between dashboard and indexer

If you’re seeing related dashboard instability, this troubleshooting guide is relevant:

Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Additional Authoritative Insight

OpenSearch documentation explicitly notes that dashboards rely entirely on valid data views (index patterns) to resolve datasets, and any mismatch will result in empty or error states rather than partial data rendering.

Wazuh’s architecture similarly depends on continuous index generation through the Wazuh indexer pipeline, meaning that “missing indices” is fundamentally a pipeline integrity issue, not a UI issue.

Fixing “No Matching Indices Found”

Once you’ve confirmed that the issue is not purely a data ingestion failure, the next step is to systematically repair the dashboard-to-index mapping and restore data visibility.

Recreate Index Patterns

A frequent root cause is a broken or missing index pattern definition in OpenSearch Dashboards.

To fix this:

• Navigate to Stack Management → Index Patterns (Data Views)
• Delete any corrupted or outdated wazuh-alerts-* patterns
• Recreate a new index pattern using:

wazuh-alerts-*

Then ensure:

• The time field is set correctly to @timestamp
• The pattern is set as default (if applicable)
• Field refresh is triggered after creation

This forces OpenSearch Dashboards to re-map available indices and rebuild field metadata.

Restart Data Pipeline Services

If indices exist but are not being properly registered, restart the full ingestion and query stack.

Restart in this order:

• Wazuh manager
• OpenSearch / Wazuh indexer
• Wazuh Dashboard

This ensures:

• Event pipeline reinitialization
• Index registry refresh
• Dashboard cache invalidation

In many environments, a stale service state prevents newly created indices from being discovered by Dashboards even when they exist.

If you are already troubleshooting dashboard instability, this is closely related:

Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Reindex or Restore Missing Data

If indices are confirmed missing or partially corrupted, you must restore or rebuild them.

Options include:

• Snapshot restore
  • Recover wazuh-alerts-* and wazuh-archives-* from OpenSearch snapshots
• Reindexing
  • Rebuild indices from archived logs if available
• Pipeline reconstruction
  • Fix broken ingestion (Filebeat/Wazuh indexer forwarder issues)

This step is critical when the root issue is not display-related but actual data loss.

Fix Permissions Issues

Even when indices exist, OpenSearch security misconfiguration can make them effectively invisible.

Check:

• Role mappings in OpenSearch Security plugin
• Index permissions for wazuh-alerts-*
• Cluster-level read access for dashboard user

Ensure the user has at minimum:

• read
• view_index_metadata
• search

on Wazuh indices.

Misconfigured RBAC often produces the same symptom as missing indices: the dashboard simply reports no matches.

Advanced Troubleshooting

If the basic fixes do not resolve the issue, the problem is likely at the cluster, template, or upgrade layer.

Check Cluster Health

Start by checking OpenSearch cluster state:

• Green → All shards allocated, healthy
• Yellow → Replicas missing, but primary shards active
• Red → Critical shard failure, data unavailable

Use:

_cat/health?v

and:

_cat/shards?v

Key issues to look for:

• Unassigned shards
• Relocation loops
• Disk watermark triggering shard allocation failure

If shards are not allocated properly, Wazuh indices may exist but remain inaccessible.

Validate Template Configuration

Wazuh relies heavily on index templates for proper ingestion.

Verify:

• wazuh-alerts-* template exists
• Mappings match expected fields (especially @timestamp)
• No conflicting legacy templates are overriding new ones

Common failure mode:

• Wrong field type mapping → indices created but not queryable
• Missing timestamp mapping → dashboards fail silently

This is especially common after partial upgrades or manual template edits.

Investigate Upgrade-Related Breakage

A large percentage of “No Matching Indices Found” cases occur immediately after upgrades.

Typical causes:

• Wazuh version introduces new index naming conventions
• OpenSearch Dashboards metadata (.kibana) becomes incompatible
• Index templates are not migrated correctly
• Security plugin schema changes break saved objects

If the issue began after an upgrade, assume:

• schema drift
• or saved object corruption

In such cases, rebuilding index patterns and reinitializing dashboard metadata is often required.

If you’re working through upgrade-related instability, this guide is relevant:

How to Stop the Infinite Wazuh Login Loop After a Version Upgrade

Preventing the Issue in Future Deployments

Preventing this class of issue requires enforcing consistency across upgrades and monitoring ingestion health proactively.

Always validate indices after upgrades

Immediately after upgrading:

• Confirm wazuh-alerts-* is actively growing
• Verify dashboards load without manual intervention
• Check index patterns still resolve correctly

Use staged upgrade process

Follow a strict upgrade order to reduce schema mismatch risk:

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

Skipping this order is a common source of index and mapping inconsistencies.

Maintain snapshot backups of .kibana and Wazuh indices

Ensure regular backups of:

• .kibana / OpenSearch Dashboards system index
• wazuh-alerts-*
• wazuh-archives-*

This allows fast recovery from:

• corrupted index patterns
• failed upgrades
• accidental deletions

Monitor ingestion lag and cluster health regularly

Proactive monitoring should include:

• Index growth rate (alerts per minute)
• Cluster health (green/yellow/red)
• Shard allocation status
• Ingestion pipeline latency

For enterprise environments, cluster monitoring is not optional—it directly prevents dashboard-level outages like this.

Preventing the Issue in Future Deployments

Preventing the “No Matching Indices Found” error in Wazuh is fundamentally about maintaining consistency across indexing, ingestion, and dashboard metadata layers.

Most production incidents occur after upgrades or configuration drift, so the goal is to enforce validation and operational discipline.

Always validate indices after upgrades

After any upgrade cycle, immediately verify:

• wazuh-alerts-* indices are actively being created
• Recent documents are present (not just empty index placeholders)
• Dashboards resolve without manual reconfiguration

A quick validation via OpenSearch APIs should be part of every deployment checklist to ensure ingestion pipelines are intact before user traffic hits the dashboard.

Use staged upgrade process

Upgrades should follow a strict dependency order to prevent schema and mapping mismatches:

1. OpenSearch (or Wazuh Indexer)
2. Wazuh Manager
3. Wazuh Dashboard

This ordering ensures:

• Index templates are already available before ingestion resumes
• Dashboard metadata aligns with updated index mappings
• No partial schema mismatch occurs during startup

Skipping this sequence is one of the most common causes of broken index resolution after upgrades.

Maintain snapshot backups of .kibana and Wazuh indices

Snapshots are essential for rapid recovery when index metadata or ingestion pipelines break.

You should regularly back up:

• .kibana / OpenSearch Dashboards system index
• wazuh-alerts-*
• wazuh-archives-*

This enables rollback in scenarios such as:

• Corrupted index patterns
• Failed upgrades
• Accidental index deletion
• Cluster instability

Without snapshots, recovery often requires full pipeline reconstruction.

Monitor ingestion lag and cluster health regularly

Proactive observability is critical for preventing silent failures.

Key metrics to monitor:

• Index ingestion rate (events per second)
• Cluster health state (green / yellow / red)
• Shard allocation status
• Queue backlog in Wazuh manager
• Disk usage thresholds affecting indexing

Early detection of ingestion lag typically prevents the “no indices match pattern” condition before it reaches the dashboard layer.

FAQ Section

Question: Why does Wazuh say “no indices match pattern”?

This error appears when the configured index pattern (commonly wazuh-alerts-*) does not match any existing indices in OpenSearch. This can happen due to:

• Missing or deleted indices
• Incorrect index pattern configuration
• Data ingestion failure from the Wazuh manager
• Time filter misalignment in the dashboard

In most cases, the root issue is that no recent data is being indexed rather than a purely UI-level problem.

Question: Can restarting Wazuh fix the issue?

Restarting services can help in limited scenarios, particularly when:

• The ingestion pipeline is temporarily stuck
• Services are in a degraded or deadlocked state
• Index discovery has not refreshed after recovery

However, restarting will not resolve the issue if:

• Indices are missing or deleted
• Index patterns are misconfigured
• Data is not being generated at all

In those cases, the underlying ingestion or storage layer must be repaired.

Question: Is this a dashboard issue or OpenSearch issue?

It can originate from either layer, but in practice:

• Most cases (≈70–80%) originate in OpenSearch
  • Missing indices
  • Broken ingestion pipeline
  • Shard or cluster failures
• Remaining cases originate in the dashboard layer
  • Incorrect index patterns
  • Corrupted .kibana / saved objects
  • Time filter or permissions misconfiguration

A proper diagnosis always starts at the index level before moving upward to the UI.

Conclusion

The “No Matching Indices Found” error in Wazuh Dashboards is rarely a single-point failure.

Instead, it typically reflects a breakdown in one or more layers of the data pipeline.

The most common root causes include:

• Missing or deleted indices in OpenSearch
• Incorrect or outdated index pattern configuration
• Ingestion failure from the Wazuh manager or agents
• Time filter or permissions misconfiguration

Resolving the issue requires a structured approach: validate indices first, then confirm ingestion, then inspect dashboard configuration and metadata.

This layered troubleshooting model ensures you isolate whether the failure is at the data generation, storage, or visualization layer, rather than guessing at the UI level.

By enforcing consistent upgrade practices, maintaining snapshots, and monitoring cluster health, you can significantly reduce the likelihood of this issue recurring in production Wazuh environments.