Checking Kibana status confirms whether the responding instance is ready to serve dashboards, saved objects, alerts, and API requests. A listening port can appear before the application is usable, so the status check helps separate startup, migration, proxy, and TLS problems during restarts, upgrades, and incident triage.
Kibana exposes two status views from the same base URL. The browser page at /status is useful for a quick visual check, while the JSON endpoint at /api/status returns the overall state, core service state, plugin state, build metadata, and runtime metrics for the individual Kibana instance that answered the request.
A detailed JSON response requires API key authentication, Basic authentication, or an authenticated user with the monitor cluster privilege when Elastic Stack security is enabled. Use the same scheme, host, port, base path, credentials, and CA trust that real clients use, because an unauthenticated request can return only a redacted overall level.
$ curl --silent --show-error --output kibana-status.json --write-out "%{http_code}\n" http://localhost:5601/api/status
200
Use the client-facing URL when a reverse proxy, server.basePath prefix, TLS listener, or load balancer sits in front of Kibana. A 503 response can still save a status document while Kibana is starting or a core dependency is unavailable.
Related: How to configure the Kibana base path
Related: How to configure TLS for Kibana
$ jq '.status.overall' kibana-status.json
{
"level": "available",
"summary": "All services and plugins are available"
}
Status levels are available, degraded, unavailable, and critical. Treat anything other than available as a reason to keep the instance out of load-balancer rotation until the affected component is understood.
$ jq '{elasticsearch: .status.core.elasticsearch.level, savedObjects: .status.core.savedObjects.level}' kibana-status.json
{
"elasticsearch": "available",
"savedObjects": "available"
}
Elasticsearch must be available for Kibana to read cluster state. Saved Objects must be available before migrations and saved object access are complete.
Related: How to connect Kibana to Elasticsearch
$ jq '{taskManager: .status.plugins.taskManager.level, security: .status.plugins.security.level, alerting: .status.plugins.alerting.level, reporting: .status.plugins.reporting.level, ruleRegistry: .status.plugins.ruleRegistry.level}' kibana-status.json
{
"taskManager": "available",
"security": "available",
"alerting": "available",
"reporting": "available",
"ruleRegistry": "available"
}
Elastic's status triage calls out taskManager, security, alerting, reporting, and ruleRegistry because failures there can affect scheduled tasks, sessions, alerts, reports, and dashboards.
$ jq '.. | objects | select(has("level") and .level != "available") | {level, summary}' kibana-status.json
No output means the saved status document did not contain a component level outside available. If output appears, inspect Kibana logs and service state before treating the instance as ready.
Related: How to set Kibana logging levels
Related: How to manage the Kibana service with systemctl in Linux
$ curl --silent --show-error --output /dev/null --write-out "%{http_code}\n" https://kibana.example.net/kibana/api/status
200
A matching public check catches TLS, reverse-proxy prefix, and listener mismatches that a localhost request cannot expose. Use a terminal for private endpoints; browser API testing can capture status, headers, and browser visibility limits for browser-visible endpoints.
Related: How to set the Kibana server host
Related: How to configure TLS for Kibana
Tool: Application Programming Interface (API) Testing Tool