Kibana Server is Not Ready Yet: Causes and How to Fix - Common Causes & Fixes

The error Kibana server is not ready yet appears on the Kibana login page when the Kibana process is running but has not finished its startup checks. The underlying cause is almost always one of: Elasticsearch is unreachable, the Kibana and Elasticsearch versions are incompatible, the .kibana system index is unhealthy, or a kibana.yml setting prevents startup. The Kibana log file (not the browser) is where the real error lives.

What This Error Means

When Kibana starts, it must complete a series of checks before it accepts traffic:

1. Bind to the configured HTTP port.
2. Resolve and connect to Elasticsearch over the URLs in elasticsearch.hosts.
3. Verify Elasticsearch is running a compatible version.
4. Migrate or open the .kibana_* system indices.
5. Start the plugin lifecycle.

If any step doesn't complete, Kibana keeps retrying and returns "server is not ready yet" to browser requests until it succeeds or you stop it. The message is the same regardless of which step is stuck - which is why the log file is the only way to know what to fix.

Common Causes

How to Fix Kibana Server Not Ready Yet

Step 1: Check the Kibana Log

On systemd hosts: journalctl -u kibana -n 200 --no-pager. In Docker: docker logs <kibana-container>. In Elastic Cloud: Stack Monitoring -> Logs. The error message in the log is specific; the browser error is generic.

Look for the first ERROR-level line that mentions Elasticsearch, migrations, version, or plugin failure.

Step 2: Verify Elasticsearch is Reachable

From the Kibana host:

curl -k -u elastic:<password> https://<elasticsearch-host>:9200

If this fails, fix the network/firewall/credentials issue first. Make sure elasticsearch.hosts in kibana.yml matches the URL you can curl.

Step 3: Check Elasticsearch Cluster Health

GET /_cluster/health

• green: cluster is healthy.
• yellow: replicas missing but primaries OK; Kibana usually still starts.
• red: at least one primary shard is unassigned. Kibana cannot start if the .kibana primaries are red.

GET /_cluster/allocation/explain

This tells you why a shard is unassigned (disk watermark, node missing, allocation filtering).

Step 4: Confirm Version Compatibility

Run GET / against Elasticsearch and check the version. Kibana requires the Elasticsearch major.minor versions to match (Kibana 8.15 requires Elasticsearch 8.15). Stack version skew is not supported across major versions.

Upgrade or downgrade so versions align. The version-skew rule is enforced at startup since the 7.x era.

Step 5: Handle Saved Object Migration Failure

The Kibana log shows unable to complete saved object migrations when a migration on the .kibana_* indices failed. Common drivers:

• Disk watermark hit on the data node holding .kibana_*.
• A cluster-state lock from a prior interrupted migration.
• Custom plugin state that can't be transformed by the new Kibana version.

Resolution path:

1. Make sure all nodes are below the high disk watermark (default 90%).
2. Check .kibana_* indices are not write-blocked: GET /.kibana*/_settings. The block index.blocks.write must be false or absent.
3. As a last resort, snapshot the .kibana_* indices before deleting them so Kibana recreates from scratch:

# Snapshot first, then if recovery is acceptable:
DELETE /.kibana_*

Deleting .kibana_* removes all saved objects (dashboards, visualizations, data views, alerts) - take a snapshot first.

Step 6: Validate kibana.yml Settings

Common misconfigurations:

elasticsearch.hosts: ["https://es01.internal:9200"]
elasticsearch.username: "kibana_system"
elasticsearch.password: "<password>"
elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/ca.crt"]
server.host: "0.0.0.0"
server.publicBaseUrl: "https://kibana.example.com"

Mismatches between elasticsearch.hosts URL and the cert SAN cause TLS errors. The kibana_system built-in user must have its password set in Elasticsearch.

Step 7: Increase Startup Patience

If Elasticsearch is slow during startup (cold cache, snapshot restore), increase the request timeout in kibana.yml:

elasticsearch.requestTimeout: 90000

See Kibana request timeout after 30000ms for the broader pattern.

Preventive Measures

1. Pin Kibana and Elasticsearch versions in deployment manifests; never let one upgrade without the other.
2. Set up cluster-health alerts on _cluster/health.status going to yellow or red.
3. Alert on disk watermarks at 75% so you act before the high watermark (90%) blocks shard allocation.
4. Snapshot .kibana_* indices as part of regular Elasticsearch snapshot policy.
5. Don't run kibana_system user with a wildcard role; lock down credentials per environment.

Resolve "Kibana Server is Not Ready Yet" Automatically with Pulse

Pulse is an AI DBA for the Elastic Stack - it covers the Elasticsearch or OpenSearch cluster that Kibana sits on top of, which is where almost every Kibana server is not ready yet failure actually originates. When the browser shows this error in your environment, Pulse:

• Continuously tracks Elasticsearch _cluster/health.status, the .kibana_* system index state (assigned, write-blocked, mid-migration), disk watermarks on the node holding .kibana_* primaries, and the running Elasticsearch and Kibana versions
• Correlates the Kibana startup failure with the underlying Elasticsearch signal - red cluster status, an unassigned .kibana_* primary from a watermark trip, a security_exception on the kibana_system user, a TLS CA mismatch on elasticsearch.hosts, or a major.minor version skew
• Identifies which of the seven causes in the table above applies, with the exact Kibana log line (unable to complete saved object migrations, Incompatible Elasticsearch version, connect ECONNREFUSED, unable to verify the first certificate)
• Recommends the precise fix - free disk on the over-watermark node, clear the index.blocks.write on .kibana_*, reset the kibana_system password, align stack versions, or raise elasticsearch.requestTimeout past 30000ms
• Applies low-risk fixes automatically with your approval (rebalancing the .kibana_* shard, clearing a stale write block, freeing disk by rolling over old indices) or generates a one-click PR

Pulse turns the manual log-plus-cluster-state correlation above into an agentic SRE workflow that resolves Kibana startup failures at the Elasticsearch layer where they originate. Start a free trial.

Frequently Asked Questions

Q: What is the fastest way to diagnose "Kibana server is not ready yet" in production?
A: Read the Kibana log directly (journalctl -u kibana -n 200 or docker logs <container>) for the first ERROR line mentioning Elasticsearch, migrations, version, or plugin failure - the browser error is generic. For continuous coverage, Pulse is an AI DBA for the Elastic Stack that correlates Kibana startup failures with the underlying Elasticsearch cluster health, .kibana_* index state, disk watermarks, and version mismatches, then recommends the specific fix.

Q: Why does Kibana say "server is not ready yet" right after restart?
A: Kibana needs to connect to Elasticsearch, verify versions, and migrate .kibana_* indices before accepting traffic. The message persists until those steps complete. Check the Kibana log for the specific stuck step - usually Elasticsearch unreachable, version mismatch, or a .kibana migration error.

Q: How long should I wait for Kibana to become ready?
A: On a healthy cluster, Kibana is ready within 30-60 seconds. Beyond 2-3 minutes the startup is stuck on a real problem (Elasticsearch unreachable, failed migration, plugin error). Don't wait it out - read the log.

Q: Can I delete the .kibana index to fix Kibana not ready?
A: Yes, but only as a last resort and only after taking a snapshot. Deleting .kibana_* indices erases all dashboards, visualizations, data views, alerts, and saved searches. Kibana will recreate empty system indices on next startup.

Q: Does Kibana need Elasticsearch to be green to start?
A: It needs the .kibana_* primary shards to be assigned, which on a single-node cluster means primaries-only (yellow is fine). On a multi-node cluster, Kibana can start with yellow status but not when .kibana_* primaries are unassigned (red).

Q: What's the difference between this error and "Kibana service is unavailable"?
A: "Server is not ready yet" means the Kibana process is running but hasn't finished startup. "Service unavailable" means the Kibana process isn't accepting connections (crashed, stopped, or behind a load balancer that can't reach it). Different layers, different fixes.

Q: Why does this error appear after an Elasticsearch version upgrade?
A: Kibana requires matching major.minor versions with Elasticsearch. Upgrading Elasticsearch first without upgrading Kibana triggers the version-mismatch check on Kibana startup. Always upgrade Kibana to match before or alongside the Elasticsearch upgrade.

Related Reading

• Kibana Elasticsearch Connection Errors: debugging connection failures
• Kibana Version Mismatch: version compatibility deep dive
• Kibana High Memory Usage: memory-related startup issues
• Kibana Request Timeout After 30000ms: timeout configuration
• What is Elasticsearch Node: cluster health and node roles
• What is Elasticsearch Index: shard allocation and .kibana_* system index