Skip to main content
Card class: Hero • Category: Cluster Health

​
At a glance

The number of nodes currently joined to the cluster and reporting healthy. This is the headcount of your cluster. It should be a flat, boring line at exactly the number you provisioned. When it drops, a node has left: it crashed, OOMed, lost network connectivity, or was fenced by the master. Every lost node triggers shard reallocation, raises load on the survivors, and (if it takes a master-eligible node below quorum) can stall the entire cluster. For a DBA, a change in this number is rarely good news unless you made it happen.
Metric basisnumber_of_nodes from GET /_cluster/health, cross-checked against GET /_cat/nodes for the per-node roster and roles.
What it countsAll nodes that have successfully joined the cluster and are reporting to the master: data nodes, master-eligible nodes, coordinating nodes, and ingest nodes.
What it excludesNodes that are configured but have not joined (a process that is up but failed cluster bootstrap), and nodes the master has already removed after a fault-detection timeout.
Aggregation windowRT: read live from cluster health each refresh.
Why it mattersNode loss is the trigger for the most disruptive cluster events: shard reallocation, recovery load, and, if master-eligible nodes drop below quorum, a cluster that cannot elect a master and stops accepting writes. The count is the single cleanest signal that something left.
Time zoneCluster clock for sampling; rendered in the team’s Vortex IQ display time zone.
Time windowRT (real-time)
Alert trigger< expected: any reading below the configured expected node count means a node has been lost, and the sensitivity alarm fires immediately. The expected count is set per cluster in the connector.
Rolesowner, engineering, operations

​
Calculation

The headline is the live number_of_nodes value from cluster health: 
node_lost = (expected_node_count - number_of_nodes) > 0
The alert compares the live count against an expected_node_count configured per cluster, rather than against a hard-coded number, because every cluster has its own topology. A 3-node cluster and a 30-node cluster both want the same rule: “tell me the moment the count drops below what I provisioned”. Because the comparison is “below expected” rather than a fixed threshold, scaling the cluster up (raising the expected count to match) does not generate false alarms. The card also reads GET /_cat/nodes to break the count down by role, which matters enormously for severity. Losing one data node out of ten is a recovery event: shards reallocate, the cluster runs hot for a while, but it stays available. Losing a master-eligible node is different: if the cluster had three master-eligible nodes and drops to two, it is still above the quorum of two, but losing a second takes it to one, below quorum, and the cluster can no longer elect a master. It then refuses writes to protect against split-brain. The role breakdown lets the card and the responder judge whether a single lost node is routine or an emergency.

​
Worked example

A platform team runs a 7-node Elasticsearch cluster: 3 dedicated master-eligible nodes and 4 data nodes, serving a product-search workload. Expected node count is configured as 7. At 16:40 BST on 21 Apr 26 the headline drops from 7 to 6.
Time (BST)Node countMasters presentData nodes presentState
16:39734GREEN, steady.
16:40633One data node (es-data-3) left; alarm fires.
16:41633Cluster goes YELLOW; es-data-3’s replicas now under-replicated.
16:42633Allocator begins rebuilding missing replicas on survivors.
16:58633Recovery complete; YELLOW persists (capacity reduced) but no data at risk.
The headline reads 6 (expected 7) in red. The on-call DBA’s read: 
Node-loss triage:
  1. Which node and which role? GET /_cat/nodes shows es-data-3 (a DATA node) is gone -> recovery event, not a quorum event. Masters intact at 3.
  2. Why did it leave? Check the survivors' logs and JVM Heap Used %: if es-data-3 hit ~95% heap before vanishing, it OOMed.
  3. Confirm masters safe: 3 master-eligible present, quorum is 2, so the cluster can still elect a master and accept writes.
  4. Watch Initializing / Relocating Shards: replicas for es-data-3's shards rebuild on the remaining data nodes.
  5. Cluster Status reads YELLOW (replicas missing) not RED (primaries intact) -> data is available, just less redundant.
The cause was an OOM on es-data-3 driven by an unbounded aggregation, the exact failure the JVM heap card is meant to pre-empt. Because the lost node was a data node and the three master-eligible nodes stayed up, the cluster remained available throughout. The team restarted es-data-3, it rejoined, the count returned to 7, and the cluster went GREEN once its shards re-replicated. Now contrast the dangerous variant: had the lost node been one of three master-eligible nodes, the count drop to 6 would be far more serious. With only two masters left the cluster still meets quorum (2 of 3), but the team is now one node away from losing the ability to elect a master and accept writes. That scenario warrants immediate replacement of the lost master node, not a routine recovery wait. Three takeaways for an ops team:
  1. The role of the lost node decides the severity. A lost data node is a recovery event; a lost master-eligible node erodes quorum and can take the whole cluster down if it cascades. Always read the role breakdown, never just the count.
  2. The count drop is the symptom; find the cause. Nodes leave for a reason: OOM (check heap), network partition (check connectivity), disk-full fencing (check storage), or a planned restart. The fix differs entirely, so diagnose before you simply restart and move on.
  3. A node that left will trigger a recovery storm. Reallocation consumes IO and CPU on the survivors, which can drag search latency up. Pair this card with Initializing / Relocating Shards and Search Latency p95 (ms) to gauge the knock-on impact.

​
Sibling cards

CardWhy pair it with Active Node CountWhat the combination tells you
Cluster Status (green / yellow / red)The data-availability consequence of node loss.A count drop that pushes status to RED means a primary went down with the node; YELLOW means only redundancy was lost.
Initializing / Relocating ShardsThe recovery storm a lost node triggers.A count drop is immediately followed by a spike here as the cluster rebuilds the lost node’s shards.
Unassigned ShardsThe interim data-loss risk.A lost node leaves its shards unassigned until recovery places copies elsewhere.
JVM Heap Used %The most common cause of a node leaving.A heap spike to ~95% just before the count drops points to an OOM as the reason the node left.
Pending Cluster TasksThe master-side load after node loss.A node leaving floods the master with routing-table updates, spiking pending tasks.
Elasticsearch Health ScoreThe composite that weights node availability.A lost node drops the composite and surfaces the event on the executive overview.

​
Reconciling against the source

Where to look in Elasticsearch’s own tooling:
GET /_cluster/health returns number_of_nodes and number_of_data_nodes; the first is the headline. GET /_cat/nodes?v&h=name,node.role,master,heap.percent,disk.used_percent lists the live roster with roles, so you can see exactly which node left and whether it was master-eligible. GET /_nodes/_local and the master node’s logs explain why a node was removed (fault-detection timeout, deliberate shutdown, OOM). GET /_cluster/state/nodes shows the authoritative node list the master is tracking. On Elastic Cloud, Stack Monitoring plots node count and per-node status; on AWS OpenSearch, the CloudWatch metric Nodes tracks the same count.
Why our number may legitimately differ from a raw health read:
ReasonDirectionWhy
Fault-detection lagBrief gapWhen a node loses network silently, the master waits out the fault-detection timeout (default 30 seconds, three pings) before removing it; for that window a raw read and our read may both still count it, or differ if sampled either side of the timeout.
Joining nodesVortex IQ may read lowerA node that has started but not finished joining the cluster is not yet in number_of_nodes; the process is up at the host level but not counted here, which is correct.
Coordinating-only nodesVariableSome operators expect the count to reflect only data nodes; our headline counts all joined nodes (matching number_of_nodes), so it may read higher than a data-node-only mental model.
Cross-connector reconciliation: node loss is a pure infrastructure signal with no ecom equivalent, but its downstream effect is real. If a node drop coincides with a search-driven revenue dip, correlate with ES Search Pool Saturation vs Ecom Burst: a smaller cluster has less search capacity, so the same traffic now saturates the survivors.

​
Known limitations / FAQs

The count dropped during a planned rolling restart. Is the alarm a false positive? Technically the node did leave, so the alarm is accurate, but the event is expected. During a planned rolling restart the count will dip by one as each node restarts and recovers; it should return to expected within a minute or two per node. If you run frequent maintenance, set a maintenance window in the connector so these planned dips do not page on-call. Why does losing a master-eligible node matter more than losing a data node? The cluster needs a quorum (a strict majority) of master-eligible nodes to elect a master and accept writes. With three master-eligible nodes the quorum is two; lose one and you are still safe but one failure away from losing write capability. Lose a data node and you only lose capacity and redundancy, which recovery restores automatically. Always check the role of the lost node first. A node left and came back on its own. What happened? Usually a transient network partition or a long GC pause that exceeded the fault-detection timeout. The master fenced the node, then the node re-established contact and rejoined. Check the node’s GC pause time and network: repeated flapping (leave/rejoin cycles) is more damaging than a single clean loss because each cycle triggers a partial reallocation. How do I set the expected node count? It is configured per cluster in the connector settings. Set it to the number of nodes you provisioned. When you scale the cluster up or down deliberately, update the expected count so the alarm reflects your new baseline rather than firing on a planned change. The cluster shows GREEN but the count is one below expected. How? This happens when the lost node held only replica shards that have already been rebuilt elsewhere, or when you removed a node deliberately and the cluster fully re-replicated. Status reflects shard availability; the node count reflects headcount. A GREEN cluster with a reduced count is running with less redundancy and capacity than you provisioned, which is worth restoring even though no data is currently at risk. Does this count coordinating-only or ingest-only nodes? Yes. number_of_nodes includes every node that has joined the cluster regardless of role, so coordinating-only and ingest-only nodes are counted. If you want to track data-node capacity specifically, read number_of_data_nodes in GET /_cluster/health; the per-role breakdown in the card detail view splits this out. Can a node be up at the host level but not counted here? Yes. A node process can be running but stuck before joining the cluster (failed discovery, bootstrap-check failure, version mismatch, or wrong cluster name). It does not appear in number_of_nodes until it successfully joins, so the host shows “up” to your infrastructure monitoring while this card correctly shows it as not part of the cluster.

​
Tracked live in Vortex IQ Nerve Centre

Active Node Count is one of hundreds of KPI pulses Vortex IQ tracks across Elasticsearch and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.