At a glance
Total Shards (primary + replica) is the count of every shard the cluster is carrying: each primary plus each of its replicas. It is the single best proxy for cluster “weight”. Every shard consumes heap for its segment metadata and cluster-state overhead, so the total drives memory pressure, recovery time, and master-node load far more than raw document or disk counts do.
What it tracks
The card reports the live total shard count for the selected period (RT), summing all primary shards and all replica copies across every index, including hidden and system indices unless they are excluded in the connector scope. The number is the sum of active_primary_shards and the replica shards reported by the cluster health and stats APIs. Watching the total matters because oversharding is one of the most common Elasticsearch performance traps: a cluster with thousands of tiny shards spends disproportionate heap on shard bookkeeping, recovers slowly after a node restart, and overloads the master with cluster-state updates. The community guideline is to keep shards in the tens-of-gigabytes range and aim for no more than roughly 20 shards per gigabyte of JVM heap on each data node. A steadily climbing total, often from daily time-based indices that are never rolled over or shrunk, is an early warning that capacity work is due. Pair it with Shard Size Skew % and Unassigned Shards to tell oversharding apart from a genuine allocation problem.
Reconciling against the source
Confirm the figure against Elasticsearch’s own tooling withGET /_cluster/health (read active_shards, which counts primaries plus assigned replicas) or GET /_cat/shards?v for the full per-shard breakdown; GET /_cat/allocation?v shows how those shards are distributed across nodes. On Elastic Cloud or AWS OpenSearch the same count appears in the cluster’s shard-allocation monitoring view. A difference usually reflects whether system or closed indices are in scope.