How to Set Up Status Page Monitoring for Elasticsearch & OpenSearch
Learn how to monitor Elasticsearch and OpenSearch cluster health and publish it to a status page so your team and customers know about search outages before they escalate.
TL;DR: Elasticsearch and OpenSearch clusters fail in subtle ways — yellow health states, shard imbalances, JVM heap pressure — long before a hard outage. Monitor cluster health API endpoints, node-level metrics, and query latency, then surface a simplified status on a public or internal status page so stakeholders get early warning instead of a support ticket flood.
Search infrastructure rarely fails all at once. It degrades — a shard goes unassigned, heap usage creeps toward 85%, and suddenly search queries that took 50ms take 4 seconds. If your team only finds out when customers complain, you're already behind.
In 2026, most teams running Elasticsearch or OpenSearch at scale treat cluster health as a first-class monitoring target, not an afterthought buried in an internal Grafana dashboard nobody checks. Here's how to build monitoring that actually catches problems and communicates them clearly.
Why Elasticsearch/OpenSearch Need Dedicated Status Monitoring
Search clusters power features users notice immediately: product search, log analysis, autocomplete, fraud detection queries. When search slows down or returns errors, the failure is visible and frustrating — but it's often invisible to generic uptime checks.
A basic HTTP ping to your search endpoint tells you almost nothing useful:
- A cluster can return HTTP 200 while sitting in yellow or red health state
- Query latency can spike 10x without a single failed request
- Node-level disk pressure can silently trigger read-only index blocks
- Shard relocation during a rebalance can degrade performance for hours
Generic "is it up" monitoring misses all of this. You need checks that understand Elasticsearch/OpenSearch internals.
Core Metrics to Monitor
1. Cluster Health Status
Both Elasticsearch and OpenSearch expose a _cluster/health API that returns green, yellow, or red status.
GET /_cluster/health
- Green: all primary and replica shards allocated
- Yellow: primary shards allocated, replicas missing — degraded resilience
- Red: at least one primary shard unassigned — data unavailable
Poll this endpoint every 30-60 seconds. A sustained yellow state for more than a few minutes deserves an alert; red should trigger immediate escalation.
2. Node Availability and Resource Pressure
Check _nodes/stats for:
- JVM heap usage (alert above 75%, page above 90%)
- Disk watermark thresholds (Elasticsearch defaults to 85% low, 90% high, 95% flood-stage read-only)
- CPU and load average per node
- Open file descriptors and thread pool rejections
Thread pool rejections (especially search and write queues) are often the earliest signal of overload — they show up before latency spikes hit dashboards.
3. Shard Allocation and Unassigned Shards
Unassigned shards are the leading cause of red cluster states. Monitor _cat/shards?h=index,shard,prirep,state,unassigned.reason to catch allocation failures early, especially after node restarts or disk pressure events.
4. Query Latency and Indexing Throughput
Track p95/p99 search latency and indexing rate over time. A cluster can be technically "green" while query latency triples due to inefficient queries, hot shards, or merge pressure. Set latency-based alerts independent of health status.
5. Snapshot and Backup Health
Failed snapshots don't cause immediate outages but create silent data-loss risk. Monitor snapshot job success/failure and alert if a scheduled snapshot is overdue by more than one interval.
Building the Monitoring Pipeline
Step 1: Instrument health checks.
Write a lightweight synthetic check that hits _cluster/health, _nodes/stats, and a representative search query on a schedule (every 30-60 seconds for production clusters). Many teams use a scheduled Lambda, cron job, or sidecar script that pushes results via webhook.
Step 2: Define thresholds that map to incident severity.
| Condition | Severity | Action |
|---|---|---|
| Cluster yellow > 5 min | Degraded | Notify on-call, log incident |
| Cluster red | Major outage | Page on-call immediately |
| Heap > 90% on any node | Degraded | Notify on-call |
| p99 latency > 2x baseline | Degraded | Notify on-call |
| Unassigned shards > 0 for 10 min | Degraded/Major | Investigate allocation |
Step 3: Push results into your status page.
Rather than exposing raw Elasticsearch metrics to customers, translate cluster state into a simplified component status: "Search — Operational," "Search — Degraded Performance," "Search — Partial Outage." This is where a tool like Livstat helps — you can create a custom monitor that pings your health-check endpoint or webhook, map its response to component states, and automatically flip your public status page when thresholds are breached.
Step 4: Separate internal and external visibility.
Your internal dashboard (Grafana, Kibana, OpenSearch Dashboards) should show raw metrics for engineers. Your status page should show customer-facing impact only — "Search results may be delayed" is more useful to a customer than "3 of 12 data nodes reporting elevated JVM heap."
Step 5: Automate incident creation.
Wire your alerting (via webhook, Slack, or PagerDuty integration) so that a red cluster health event automatically opens an incident on your status page, not just an internal alert. Manual incident creation during a real outage adds delay exactly when speed matters most.
Common Pitfalls to Avoid
Alerting only on red, not yellow. Yellow clusters often precede red states by hours. Catching yellow early prevents escalation.
Ignoring per-node metrics in favor of cluster-wide averages. One overloaded node can degrade an entire query path even if cluster averages look fine.
No baseline for "normal" latency. Without a baseline, you can't detect relative degradation — absolute thresholds alone miss slow creep.
Treating snapshot failures as low priority. A string of failed backups discovered during a real outage is a compounding disaster.
Not testing failover scenarios. Simulate node loss in staging to confirm your monitoring actually detects and alerts on the failure modes you expect.
OpenSearch-Specific Considerations
If you're running OpenSearch instead of Elasticsearch (common since the license fork), the APIs are nearly identical, but watch for:
- Different default security plugin behavior affecting API access for health checks
- OpenSearch's Index State Management (ISM) plugin failures, which can silently stop rollovers and fill disks
- Divergent version-specific bug fixes — always check release notes when upgrading, since health-check API responses have occasionally changed between major versions
Key Takeaway
Elasticsearch and OpenSearch clusters degrade gradually, and gradual degradation is exactly what generic uptime checks fail to catch. Monitor cluster health, node resources, shard allocation, and query latency directly, set severity-based thresholds, and pipe that data into a status page that communicates real customer impact — not raw metrics. Do this right, and you'll catch search degradation while it's still a yellow cluster, not a red one your customers already noticed.
