Kibana: Query, Visualize, and Manage Elasticsearch Data

What Problem Kibana Solves and Who It Is For

Elasticsearch stores documents and makes them searchable through a JSON HTTP API. Without a visual layer, exploring millions of log events means constructing raw queries, reading JSON responses, and writing custom tooling for each analysis task. Kibana provides that layer in a browser, connecting engineers directly to the data they already have in Elasticsearch.

The primary audience is engineering teams using Elasticsearch for centralized log collection, application performance monitoring, or event-driven search. Three entry points cover most use cases. The Discover view lets analysts filter live log streams using the Kibana Query Language. The Dashboard section lets teams assemble and arrange visualizations on any Elasticsearch index. The Dev Tools console runs arbitrary Elasticsearch Query DSL requests and Painless scripts directly from the browser, which matters most when building complex aggregations or diagnosing index problems.

Kibana is not a general analytics platform. It does not connect to SQL databases, Prometheus, or any data store other than Elasticsearch, and it does not generate reports independently of that backend. Its value is precisely its tight integration with Elasticsearch's document model.

Architecture: The Browser-to-Elasticsearch Proxy

Kibana runs as a Node.js server. The browser connects to Kibana's HTTP endpoint, and Kibana in turn communicates with Elasticsearch's REST API. All queries typed in the UI pass through this proxy layer, which handles authentication, index-pattern resolution, and response formatting before data reaches the browser.

The repository is primarily TypeScript. The main entry point is the Node.js process started from the `scripts/kibana` script, and the `kibana.d.ts` file at the repository root exposes TypeScript type definitions for plugin developers who need to extend Kibana's UI. Configuration lives under the `config/` directory. The `examples/` directory in the repository holds reference implementations for plugins covering content management, embeddable panels, ES|QL validation, and other extension points, making it the main starting point for teams building custom Kibana plugins.

The hosted cloud version at elastic.co/cloud runs this same architecture but removes the operational burden of managing both the Kibana process and the Elasticsearch cluster.

Getting Kibana Running: Download, Cloud, and Source Build

For production, the README directs engineers to the download page at elastic.co/downloads/kibana, where official packages for Linux, macOS, and Windows are available. Elastic also provides a hosted version through its cloud service, which handles provisioning of both Elasticsearch and Kibana together.

For contributing code or testing unreleased features, the repository's CONTRIBUTING.md file contains the full local setup steps. Once the repository is cloned and dependencies are installed, starting Kibana in development mode uses the debug script from the repository's package.json:

node --nolazy --inspect scripts/kibana --dev

Running with `--dev` enables source-map support and automatic reload on file changes. To produce production build artifacts for all supported platforms:

node scripts/build --all-platforms

The `--all-platforms` flag is required to produce the full set of release tarballs. Building from source requires the Node.js version pinned in the repository's `.node-version` file; the `.nvmrc` file provides the same value for nvm users.

The main branch tracks version 9.6.0 as of the most recent package.json. The most recent stable releases available at the time of writing were Kibana 9.5.4 and 9.4.7 for the version 9 line, and 8.19.22 for the version 8 line.

Version Compatibility Rules and Upgrade Constraints

The README documents precise compatibility rules between Kibana and Elasticsearch, and violating them causes either a fatal startup error or a logged warning.

Major version numbers must strictly match. Running Kibana 9.x against Elasticsearch 8.x is a fatal error, as is running Kibana 8.x against Elasticsearch 9.x. Within the same major, Kibana has limited flexibility. It can run one or more patch versions ahead of Elasticsearch (Kibana 9.4.2 against Elasticsearch 9.4.0) with only a logged warning, which is the intended path for Kibana-only patch upgrades. It can also run a minor version behind Elasticsearch (Kibana 9.3.x against Elasticsearch 9.4.x) with a logged warning, to simplify rolling upgrades.

Running Kibana on a newer minor version than Elasticsearch (Kibana 9.4.x against Elasticsearch 9.3.x) is a fatal error. The same applies to Kibana being on an older patch than Elasticsearch (Kibana 9.4.0 against Elasticsearch 9.4.1), which logs a warning.

The README states that support and troubleshooting begin only after bringing both services to a matching version when issues arise on mismatched combinations. This means that before any upgrade, teams must plan the Elasticsearch upgrade first, then bring Kibana to match, to avoid downtime from version-mismatch startup failures.

For organisations running the version 8 line alongside version 9, note that the major versions are separate tracks: Kibana 8 cannot connect to Elasticsearch 9 under any configuration.

Where Kibana Falls Short

Kibana's tight coupling to Elasticsearch is also its main limitation. Teams with data in PostgreSQL, MySQL, Prometheus, or other backends cannot build a unified Kibana dashboard over those sources without routing all data through Elasticsearch first. The entire query model, KQL, ES|QL, and the index-pattern system, is built around Elasticsearch's inverted index structures.

The README does not document rollback procedures for version upgrades. If a Kibana upgrade introduces a problem, reverting requires manually restoring the previous binary and verifying that the saved-object schema in Elasticsearch remains compatible. That process is not documented in the repository's README.

Kibana also requires running a separate Elasticsearch instance. It does not embed its own storage. For teams that need only a log viewer without a full Elastic Stack, the operational overhead of maintaining two services (plus optional Logstash or Beats pipelines) may be disproportionate to the benefit.

The license is listed as NOASSERTION in the repository metadata. Elastic distributes Kibana under a dual licensing model combining its Elastic License and the Server Side Public License, with some source files under Apache 2.0. Teams deploying Kibana commercially should verify which files are covered by which license in the current release before distribution.

Kibana vs Grafana: Different Starting Points

The most common alternative is Grafana, an open source visualization platform that connects to a wide range of backends including Prometheus, InfluxDB, Loki, PostgreSQL, and MySQL. Grafana's multi-source model makes it the default choice for teams that store metrics in Prometheus and logs elsewhere, since a single Grafana instance can query both in the same dashboard.

Kibana's advantage is depth within the Elastic Stack. Dev Tools supports the full Elasticsearch Query DSL, the Painless scripting language, and the newer ES|QL syntax directly from the browser. The Discover view with KQL is optimized for full-text log search on Elasticsearch's inverted index, while Grafana's Log panel is built primarily around label-based log stores like Loki. Index management, snapshot repositories, and security role configuration are accessible through Kibana's management section; Grafana does not provide equivalents for those Elasticsearch administrative tasks.

For a team already committed to Elasticsearch as the primary data store, Kibana offers purpose-built tooling that Grafana cannot replicate for Elasticsearch-specific operations. For a team running a heterogeneous observability stack with multiple backends, Grafana's multi-source support makes it the more practical choice.

Editorial conclusion

Teams already running Elasticsearch for log collection, application event data, or full-text search should adopt Kibana as the standard interface. Teams that need dashboards over multiple data sources (Prometheus, PostgreSQL, and others alongside Elasticsearch) will find Grafana's multi-backend model a better fit. Before deploying, verify that the Kibana major version matches the Elasticsearch major version exactly; a mismatch at that level causes a fatal startup error that blocks the process entirely.

Frequently asked questions

Official sources

1. elastic/kibana on GitHub
2. Issues
3. Project website
4. README
5. Releases