Checking Kibana status confirms whether the instance behind the current listener, reverse proxy, or load balancer is actually ready to serve dashboards, saved objects, alerting, and API traffic. A fast status check separates a routing or TLS problem from a Kibana startup problem during restarts, upgrades, and incident response.

Kibana exposes two status views from the same base URL: the human-readable /status page and the JSON /api/status endpoint. The API response includes the overall state, core services such as elasticsearch and savedObjects, plugin-specific states, build metadata, and runtime metrics, which makes it the better target for scripted checks.

The status API can legitimately return 503 with an overall level of unavailable while Kibana is still starting or while saved object migrations are blocked. When security is enabled, unauthorized requests receive only a minimal response, so use the same scheme, host, port, credentials, CA trust, and optional server.basePath prefix that the real clients use.

Related: How to connect Kibana to Elasticsearch
Related: How to configure the Kibana base path
Related: How to manage the Kibana service with systemctl in Linux

Steps to check Kibana status:

  1. Request the JSON status document from the same base URL that browsers or load balancers use. 
    $ curl --silent --show-error http://localhost:5601/api/status | jq
{
  "name": "kibana-01",
  "uuid": "8b7d017c-edeb-4e21-843d-6dfcbaa776b7",
  "version": {
    "number": "9.1.4",
    "build_hash": "a8042692500503cca8f3d4aed3c38da398c22f9d",
    "build_number": 88877,
    "build_snapshot": false,
    "build_flavor": "traditional",
    "build_date": "2025-09-16T20:15:09.834Z"
  },
  "status": {
##### snipped #####
  }
}

    When Elastic Stack security is enabled, add either --user elastic or an Authorization: ApiKey header because unauthorized requests receive only a minimal redacted status response.

    Use the client-facing https:// URL, add --cacert /path/to/ca.crt when TLS uses a private CA, and include any configured server.basePath prefix before /api/status.

    Open /status in a browser when a human-readable status page is more useful than raw JSON.

    Related: How to configure the Kibana base path

  2. Save the response body and check the HTTP status code when deciding whether Kibana is ready or still starting. 
    $ curl --silent --show-error --output /tmp/kibana-status.json --write-out "%{http_code}\n" http://localhost:5601/api/status
200

    A 503 response with a body such as {"status":{"overall":{"level":"unavailable"}}} means Kibana has not finished starting or a blocking dependency such as saved object migration is still unresolved.

    Reverse proxies, SSO gateways, and web application firewalls can turn the same check into 302, 401, or 403 if the request is sent to the wrong public path or without the required authentication.

  3. Inspect the overall, elasticsearch, and savedObjects states first, because current Elastic troubleshooting guidance starts with those core checks. 
    $ jq '{overall: .status.overall, elasticsearch: .status.core.elasticsearch, savedObjects: .status.core.savedObjects}' /tmp/kibana-status.json
{
  "overall": {
    "level": "available",
    "summary": "All services and plugins are available"
  },
  "elasticsearch": {
    "level": "available",
    "summary": "Elasticsearch is available",
    "meta": {
      "warningNodes": [],
      "incompatibleNodes": []
    }
  },
  "savedObjects": {
    "level": "available",
    "summary": "SavedObjects service has completed migrations and is available",
    "meta": {
      "migratedIndices": {
        "migrated": 0,
        "skipped": 0,
        "patched": 8
      }
    }
  }
}

    If savedObjects is unavailable, treat the instance as not ready even when the web server itself answers requests, because upgrades and plugin initialization are still incomplete.

    Related: How to connect Kibana to Elasticsearch

  4. Check the common dependency plugins that usually explain why application features are not usable yet. 
    $ jq -rc '.status.plugins|to_entries[]|select(.key=="taskManager" or .key=="security" or .key=="alerting" or .key=="reporting" or .key=="ruleRegistry") | {plugin: .key, level: .value.level, summary: .value.summary}' /tmp/kibana-status.json
{"plugin":"alerting","level":"available","summary":"Alerting is (probably) ready"}
{"plugin":"reporting","level":"available","summary":"All services and plugins are available"}
{"plugin":"ruleRegistry","level":"available","summary":"All services and plugins are available"}
{"plugin":"security","level":"available","summary":"All services and plugins are available"}
{"plugin":"taskManager","level":"available","summary":"Task Manager is healthy"}

    Plugin failures can cascade, so fix taskManager, security, or alerting before chasing symptoms in dashboards or alert rules.

  5. Search the saved response for any degraded, unavailable, or critical component levels when the summary line is not enough. 
    $ jq -rc '.. | objects | select(has("level") and (.level == "degraded" or .level == "unavailable" or .level == "critical")) | {level, summary, detail}' /tmp/kibana-status.json

    No output means the saved status document does not contain any non-available components.

    If this step returns matches, move to service and log checks before treating the node as ready.

    Related: How to set Kibana logging levels
    Related: How to manage the Kibana service with systemctl in Linux

  6. Repeat the HTTP code check through the public host name, TLS scheme, and optional base path that clients actually reach. 
    $ curl --silent --show-error --output /dev/null --write-out "%{http_code}\n" https://kibana.example.net/kibana/api/status
200

    This final check catches proxy prefix, certificate, and listener mismatches that a plain http://localhost:5601/api/status check cannot see.

    Related: How to configure the Kibana base path
    Related: How to set the Kibana server host and port
    Related: How to configure TLS for Kibana