Monitor Elasticsearch.
Cluster health, unassigned shards, JVM heap and GC pressure, search and indexing performance, thread pool rejections, and circuit breaker trips. Point the agent at one node — it discovers the rest of the cluster.
Complete Elasticsearch observability.
The Watchlog Agent needs one reachable endpoint. Every node, index, shard and thread pool is discovered from the cluster itself.
_cluster/health.statusCluster HealthGreen, yellow or red — scored with context, not as a raw threshold
unassigned_primary_shardsUnassigned Primary ShardsThe shards whose absence means data is genuinely unavailable
jvm.mem.heap_used_percentJVM Heap UsagePer node, judged on sustained pressure rather than a single spike
jvm.gc.collectors.old.collection_time_in_millisGC Pause TimeOld-generation pauses as a share of wall-clock time
indices.search.query_totalSearch RateQueries per second across the cluster and per index
query_time_in_millis / query_totalQuery LatencyMean query and fetch time over the interval, never the lifetime average
indices.indexing.index_totalIndexing RateDocuments indexed per second, counted per primary shard
indices.indexing.index_failedIndexing FailuresOperations Elasticsearch rejected, usually a mapping conflict
thread_pool.search.rejectedThread Pool RejectionsEvery rejection is a request the cluster dropped rather than served
breakers.parent.trippedCircuit Breaker TripsRequests refused to protect the heap — an event, not a warning sign
fs.total.available_in_bytesDisk vs. WatermarkMeasured against your configured low, high and flood-stage watermarks
indices.merges.total_throttled_time_in_millisMerge ThrottlingWhen merges fall behind writes, indexing latency follows
Your cluster at a glance.
Seven tabs — Overview, Performance, Nodes, Indices, Shards, Slow Operations and Diagnostics — activate the moment you enable the integration.
Watchlog scores cluster health with context, not thresholds. A cluster with one data node cannot allocate a replica anywhere, so yellow is its correct steady state — Watchlog says so instead of paging you. Disk is judged against your own configured watermarks, not a hardcoded 85%.
What engineers use Elasticsearch monitoring for.
Unassigned shard triage
See every unassigned shard with Elasticsearch's own reason, and a cached allocation explanation translated into one plain sentence — "all eligible nodes exceed the configured disk watermark" rather than a decision tree.
Heap pressure and GC
Track heap per node alongside garbage collection time as a share of wall clock. Two hundred collections costing 2 ms each is healthy; four costing 900 ms each is not, and only one of those is visible in a count.
Search latency regression
Find which index regressed, not just that the cluster got slower. Per-index query and fetch latency, ranked, with slow searches from the Elasticsearch slow log when you have one configured.
Capacity and watermark planning
Watch disk against the watermarks your cluster actually uses, with alerts before the high watermark starts relocating shards under load and long before flood stage makes indices read-only.
Signals that mean something.
Elasticsearch produces thousands of numbers. Watchlog turns them into the handful that predict an incident — and explains each one in a sentence.
- ✓Know whether yellow means "one data node" or "a primary shard is missing" — Watchlog distinguishes them
- ✓Catch thread pool rejections, which are dropped user requests, not just a busy moment
- ✓See circuit breaker trips as the events they are, separately from elevated utilisation
- ✓Compare nodes against the cluster median, so one pathological node cannot hide inside an average
- ✓Track index growth and project it against free disk before ILM becomes urgent
- ✓Get every deduction in the health score explained in a sentence, with a recommendation attached
Watchlog never touches your cluster.
The integration issues read requests only, and that is enforced in code rather than by convention — there is no path through which it can express a mutation.
- ✕DELETE or PUT of any index
- ✕_cluster/reroute
- ✕Cancelling a running task
- ✕Closing or opening an index
- ✕_forcemerge, _flush or cache clears
- ✕Updating cluster or index settings
- ✕Enabling slow logs on your behalf
- ✕Changing replica counts or watermarks
- ✓Reads cluster health, node, index and shard stats
- ✓Explains why a shard cannot be allocated
- ✓Tells you which command would fix it
- ✓Scrubs query text on your host before it leaves
- ✓Withholds document bodies by default
- ✓Degrades one section when a privilege is missing
- ✓Skips _cluster/state entirely on large clusters
- ✓Runs hot threads only when you press the button
Minimum privileges: the monitor cluster privilege and monitor on the indices you want covered. Administrator access is never required — and if one API is unreadable, only that section is disabled while everything else keeps working.
Elasticsearch monitoring in under 2 minutes.
One endpoint and a monitoring user. No per-node configuration, no sidecar on every pod.
Install the Watchlog Agent
Deploy the agent on any host that can reach your cluster. It does not have to be an Elasticsearch node.
Add one endpoint
Host, port and a monitoring user — or an API key. The agent discovers every other node from there.
Dashboard populates in 60s
Cluster health, nodes and shards appear within a minute; index detail on the next collection cycle.
sudo apiKey="$WATCHLOG_API_KEY" server="$WATCHLOG_SERVER" MEMORY="300M" bash -c "$(curl -L https://watchlog.io/ubuntu/watchlog-script.sh)The agent detects Elasticsearch on port 9200 during its discovery scan. Add a monitoring user and the whole cluster appears — nodes, indices and shards included.
Start monitoring Elasticsearch now.
Full cluster visibility in under 2 minutes. No credit card required.
Questions? Contact us at [email protected]