By default, a new encryption key is generated for the reporting features each time you start Kibana. This means if a static encryption key is not persisted in the Kibana configuration, any pending reports will fail when you restart Kibana.

    If you are load balancing across multiple Kibana instances, they need to have the same reporting encryption key. Otherwise, report generation will fail if a report is queued through one instance and another instance picks up the job from the report queue. The other instance will not be able to decrypt the reporting job metadata.

    If you divide workspaces in an Elastic cluster using multiple Kibana instances with a different kibana.index setting per instance, you must set a unique setting per kibana.index. Otherwise, report generation will periodically fail if a report is queued through an instance with one kibana.index setting, and an instance with a different kibana.index attempts to claim the job.

    Kibana instance A:

    If security is enabled, the setting should begin with .reporting- in order for the kibana_system role to have the necessary privileges over the index.

    If your Kibana instance requires a reverse proxy (NGINX, Apache, etc.) for access, because of rewrite rules or special headers being added by the proxy, then you need to configure the xpack.reporting.kibanaServer settings to make the headless browser process connect to the proxy in .