This section collects common installation or usage problems on the Wazuh Kibana plugin, and some basic steps to solve them.

"Incorrect Kibana version in plugin [wazuh]" when installing the Wazuh Kibana plugin

The Wazuh Kibana plugin has a file named package.json, it includes dependencies along more information. One of them is the Kibana version:

"kibana": {
  "version": "6.7.2"

Your Wazuh Kibana plugin must match the installed Kibana version. If the version field in the package.json file is 6.7.2 then your installed Kibana version must be 6.7.2.

You can check our compatibility matrix to learn more about product compatibility between Wazuh and the Elastic Stack.

No template found for the selected index pattern

Elasticsearch needs a specific template to store Wazuh alerts, otherwise visualizations won't load properly. You can insert the correct template using the following command:

# curl | curl -X PUT "http://localhost:9200/_template/wazuh" -H 'Content-Type: application/json' -d @-


Indices with the wrong template will need to be reindexed. You can follow our reindexation guide.

Wazuh API seems to be down

It means your Wazuh API could be unavailable. Since the Wazuh Kibana plugin needs data from the Wazuh API, it must be available for the Wazuh Kibana plugin.

If you are using systemd, please check the status as follow:

# systemctl status wazuh-manager

If you are using SysV Init, please check the status as follow:

# service wazuh-manager status

If the Wazuh API is running, try to fetch data using the CLI from the Kibana server:

# curl api_user:api_pass@api_url:55000/version

If the curl command fails but the Wazuh API is running properly, it means you have a connectivity problem between servers.

I don't see alerts in the Wazuh Kibana plugin

The first step is to check if there are alerts in Elasticsearch.

# curl <ELASTICSEARCH_IP>:9200/_cat/indices/wazuh-alerts-3.x-*

If you don't see any Wazuh related index, it means you have no alerts stored in Elasticsearch.

Check if Filebeat is reading the alerts.json file:

# lsof /var/ossec/logs/alerts/alerts.json

There should be two processes reading the alerts.json file: ossec-analysisd and filebeat.

API version mismatch. Expected vX.Y.Z

The Wazuh Kibana plugin uses the Wazuh API to fetch information, being compatible between patch versions. For example, you can use an Wazuh Kibana plugin designed for Wazuh 3.7.2 with a Wazuh API 3.7.1.

You can't use the 3.7.2 version of Wazuh API with a Wazuh app designed for Wazuh 4.0.4.

Routes. Error. Cannot read property 'manager' of undefined

This error usually means that you're using Wazuh v2.x with Elastic Stack v6.x, or Wazuh v3.x with Elastic Stack v5.x.

You have to use the correct versions of Wazuh and the Elastic Stack to work properly. We always recommend upgrading to the latest version following this guide.

Failed to parse date field with format dateOptionalTime

This error message appears when clicking on the View surrounding documents or View single document buttons from an alert on the Discover tab. This is due to a breaking change introduced on Wazuh 3.7.0.

In previous versions of Wazuh, the Elasticsearch template had these properties for the @timestamp field:

"@timestamp": {
  "type": "date",
  "format": "dateOptionalTime"

As of Elastic Stack 6.4.x, the date format causes an error when viewing the surrounding documents, and to fix this, the Elasticsearch templated was updated:

"@timestamp": {
  "type": "date"

This change is not critical and won't cause any data loss on Elasticsearch. For now, the only case where this issue appears is on the View surrounding documents option. After updating Wazuh and the Elastic Stack following our upgrading guide, the new template will be in use, and the next daily indices will be created using the new date format.

However, if you want to fix this problem for the affected indices, there are different options that you can try in order to correct them:


The following methods require stopping the Filebeat service before proceeding. After finishing, you can restart it again.

  • Reindex indices: The most basic form of reindexation consists of copying the documents from one index to another. In this case, we use this procedure to create a new index using the updated template, so we can then remove the old one, and finally, reindex the new index into the previous one.

    On the Elasticsearch documentation you can find more info about the Reindex API.

  • Close indices: Closing an index will be blocked for read/write operations, so it won't be used when visualizing alerts on Kibana, although the data will be still available for archiving purposes.

    On the Elasticsearch documentation you can find more info about the Open/Close index API.

  • Delete indices: This method is not suitable for production environments where all the data must be stored or archived. It's more convenient for testing environments, since it's the fastest method to fix the issue.

    On the Elasticsearch documentation you can find more info about the Delete index API.

This breaking change could lead into a X of Y shards failed message because of the presence of old and new Elasticsearch indices using different templates, but it's not critical or harmful.

None of the above solutions are fixing my problem

All the technologies we are using have their own logs files, you can check them and look for error and warning messages.

  1. Check the Elastic Stack log files:

    # cat /var/log/elasticsearch/elasticsearch.log | grep -i -E "error|warn"
    # cat /var/log/filebeat/filebeat | grep -i -E "error|warn"


    The Elastic Stack uses the /var/log folder to store logs by default. This setting can be customized following the documentation for Elasticsearch or Filebeat.


    By default, Kibana doesn't store logs on a file. It can be configured with the logging.dest setting in the kibana.yml configuration file. Check the Kibana documentation for more details.

  2. Check the Wazuh Kibana plugin log file:

    # cat /usr/share/kibana/optimize/wazuh/logs/wazuhapp.log | grep -i -E "error|warn"
  3. Check the Wazuh manager log file:

    # cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"

You can also open a new thread in our Google mailing list, or a new issue in our GitHub repository.