Troubleshoot a Kibana connection failure

A Kibana connection error often means Kibana cannot reach Elasticsearch, but the browser-to-Kibana connection or a reverse proxy can fail too. Start with the failed request and Kibana's server logs; a generic UI message does not identify the failing hop.

Test the Elasticsearch connection from Kibana's environment

For a secured deployment, test the same hostname and CA that Kibana uses:

curl --cacert /etc/kibana/ca.crt -u kibana_system \
  https://es-host:9200/

With only a username supplied, curl prompts for the password. Run the test from the Kibana host or container, not merely from your laptop. A connection timeout, certificate error, and HTTP 401 indicate different problems.

A local unsecured development cluster can instead be tested with curl http://localhost:9200/. Use the protocol actually configured on Elasticsearch.

Check addresses, credentials, and trust

A typical kibana.yml configuration for basic authentication is:

elasticsearch.hosts: ["https://es-host:9200"]
elasticsearch.username: "kibana_system"
elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/ca.crt"]

Store elasticsearch.password in the Kibana keystore rather than committing a password into configuration. A supported service account token is another authentication option; do not configure it alongside basic credentials. kibana_system is the server account, not a user's browser login.

In Docker, localhost refers to the Kibana container itself. Use the Elasticsearch service's network name. In Kubernetes, use the appropriate Service name, including its namespace when required, and check endpoints and network policies.

Elasticsearch security auto-configuration can enable HTTP TLS, but not every upgraded or manually configured installation uses HTTPS. Confirm the actual deployment. Repair CA trust or hostname mismatches rather than leaving certificate verification disabled.

Check versions and error details

Use a supported Elasticsearch/Kibana version combination; matching the full stack version is the normal steady-state target. Matching only the major number is insufficient. Temporary mismatches during a documented rolling upgrade have specific constraints.

“Unable to revive connection” describes a connection that the client could not restore. It can reflect network, authentication, TLS, or availability problems, so a successful TCP port check alone does not settle it.

If curl succeeds, compare the runtime configuration, credentials, CA path permissions, and DNS resolution used by Kibana. If the browser still fails while Kibana can reach Elasticsearch, inspect proxy routing, browser requests, and Kibana's public URL configuration.

See Kibana's Elasticsearch connection settings.