Cluster health API in Elasticsearch - Step-by-Step Execution

Concept Flow - Cluster health API

Send HTTP GET request to /_cluster/health

↓

Elasticsearch receives request

↓

Check cluster state: nodes, shards, status

↓

Prepare JSON response with health info

↓

Send JSON response back to client

↓

Client reads cluster health status

The client sends a request to the cluster health API, Elasticsearch checks cluster status, then returns a JSON with health details.

Execution Sample

Elasticsearch

GET /_cluster/health

Response:
{
  "cluster_name": "my_cluster",
  "status": "green"
}

This request asks Elasticsearch for the cluster health, which responds with the cluster name and status.

Execution Table

Step	Action	Request/Response	Result
1	Client sends GET request to /_cluster/health	GET /_cluster/health	Request received by Elasticsearch
2	Elasticsearch checks cluster state	Internal check	Determines nodes, shards, and status
3	Elasticsearch prepares JSON response	Response JSON	{"cluster_name":"my_cluster","status":"green"}
4	Elasticsearch sends response to client	Response sent	Client receives cluster health data
5	Client reads status field	status: green	Cluster is healthy

💡 Response sent and client received cluster health status, process ends.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
cluster_name	undefined	my_cluster	my_cluster	my_cluster
status	undefined	green	green	green
request	undefined	GET /_cluster/health	GET /_cluster/health	GET /_cluster/health
response	undefined	undefined	{"cluster_name":"my_cluster","status":"green"}	{"cluster_name":"my_cluster","status":"green"}

Key Moments - 3 Insights

Why does the client get a 'green' status even if some nodes are down?

The 'green' status means all primary and replica shards are allocated. Some nodes can be down if shards are still healthy, as shown in step 2 and 3 of the execution_table.

What does the 'status' field represent in the response?

The 'status' field shows overall cluster health: 'green' means all shards are allocated, 'yellow' means some replicas are unassigned, 'red' means some primary shards are unassigned. See step 5 in execution_table.

Can the cluster health API response change between requests?

Yes, because cluster state can change anytime. Each request triggers a fresh check (step 2), so the response (step 3) may differ.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cluster status after step 3?

A "green"

B "yellow"

C "red"

D "unknown"

💡 Hint

Check the 'Result' column in row 3 of execution_table for the JSON response.

At which step does Elasticsearch prepare the JSON response?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' column in execution_table to find when response is prepared.

If the cluster had unassigned primary shards, how would the 'status' value change in variable_tracker?

A "green"

B "red"

C "yellow"

D "blue"

💡 Hint

Refer to key_moments explanation about 'status' meanings and variable_tracker 'status' variable.

Concept Snapshot

Cluster health API syntax:
GET /_cluster/health

Returns JSON with cluster_name and status.
Status values: green (all good), yellow (some replicas missing), red (primary shards missing).
Used to monitor cluster health quickly.

Full Transcript

The Cluster health API in Elasticsearch lets clients check the health of the cluster by sending a GET request to /_cluster/health. Elasticsearch receives this request, checks the current state of nodes and shards, then prepares a JSON response containing the cluster name and health status. The status can be green, yellow, or red, indicating how healthy the cluster is. The client reads this response to understand cluster health. This process repeats each time the API is called, reflecting the current cluster state.