At a glance
HTTP Connections In Use is the count of currently open HTTP connections to the cluster’s REST layer, read from node stats. It is a live capacity gauge: how many clients (application servers, ingest pipelines, Kibana, monitoring agents) are talking to Elasticsearch right now. A steady number tracks your normal client fleet; a sudden climb usually means a client is leaking connections or a traffic burst is in flight.
What it tracks
The value comes from the HTTP section ofGET /_nodes/stats/http, specifically http.current_open aggregated across nodes (Elasticsearch also exposes http.total_opened as a lifetime counter). It counts established connections to the REST/HTTP layer, not the internal transport connections nodes use to talk to each other. Most application clients pool and reuse connections, so a healthy figure is stable and proportional to your client count rather than your request rate: thousands of requests per second can ride over a few hundred pooled connections. Read it alongside HTTP Connection Saturation %, which expresses the same pressure as a percentage of the configured ceiling. A monotonic climb that never settles is the classic signature of a client that opens connections without closing them, eventually exhausting file descriptors on the node.
Reconciling against the source
Confirm the live figure withGET /_nodes/stats/http (field http.current_open) or the one-line GET /_cat/nodes?v&h=name,http.current_open. In managed services the same signal appears as the HTTP/current-connections metric on the Elastic Cloud, AWS OpenSearch/Elasticsearch Service (CloudWatch) or Bonsai console. Small differences from a manual check are just poll timing: the card samples every 60 seconds while the native call is instantaneous.