🚨 Telegraf Error Guide: '[outputs.elasticsearch] no Elasticsearch node available' — Fix Cluster Connectivity

Overview

The elasticsearch output writes metrics as documents and runs a periodic node health check. When that health check cannot reach a usable node before it times out, Telegraf refuses to write and logs:

2026-07-12T12:00:00Z E! [outputs.elasticsearch] Error in plugin: health check timeout: no Elasticsearch node available

When the node is reachable but rejects credentials, the failure surfaces at the auth layer instead:

E! [outputs.elasticsearch] Error in plugin: elastic: Error 401 (Unauthorized): missing authentication credentials for REST request [/_nodes/http]

Telegraf buffers metrics while the output is unhealthy; if the buffer fills, the oldest metrics are dropped and no documents are indexed.

Symptoms

• No metric documents appear in Elasticsearch while other outputs succeed.
• journalctl -u telegraf repeats health check timeout: no Elasticsearch node available each flush.
• curl to the cluster URL from the Telegraf host fails, hangs, or returns 401/security_exception.
• internal_write shows rising buffer_size and eventual metrics_dropped for the elasticsearch output.
• Cluster health is red (or the node is restarting), so the health check never returns a usable node.

Common Root Causes

• Wrong URL, scheme, or port — pointing at 9300 (transport) instead of 9200 (HTTP), or http:// against a TLS-only node.
• Cluster unreachable or unhealthy — the node is down, restarting, or the cluster is red, so the health check finds no available node.
• Authentication failure — X-Pack/OpenSearch security is enabled but username/password are missing or wrong, giving 401.
• TLS trust/verification failure — a self-signed or private-CA cert without tls_ca, or a hostname mismatch.
• Health check too aggressive — a very short health_check_timeout/health_check_interval against a slow or loaded cluster marks healthy nodes as unavailable.
• Firewall / security group — TCP/9200 is blocked between the Telegraf host and the cluster.
• Index template / mapping conflict — the target index or template is misconfigured, so writes fail even when the health check passes (a follow-on error after connectivity).

Diagnostic Workflow

First reproduce the health check with curl from the Telegraf host — the output hits /_nodes/http and /_cluster/health, so query those directly:

# Basic reachability and version
curl -sS -u "${ES_USER}:${ES_PASSWORD}" https://10.0.0.30:9200/ | head

# The endpoints the output relies on
curl -sS -u "${ES_USER}:${ES_PASSWORD}" https://10.0.0.30:9200/_cluster/health?pretty
curl -sS -u "${ES_USER}:${ES_PASSWORD}" https://10.0.0.30:9200/_nodes/http?pretty | head

Confirm the port is open and check whether the failure is connectivity, auth, or TLS:

nc -z -v 10.0.0.30 9200
# A 401 body means auth; a curl 'certificate' error means TLS trust; a hang means firewall/down.

Run only the output path with debug to watch the health check and write attempts:

telegraf --config /etc/telegraf/telegraf.conf --test-wait 20 --debug 2>&1 | grep -i elasticsearch

A correct output config pins HTTPS, auth, TLS trust, and a health-check interval sized for the cluster:

[[outputs.elasticsearch]]
  urls = ["https://10.0.0.30:9200"]
  username = "${ES_USER}"
  password = "${ES_PASSWORD}"
  index_name = "telegraf-%Y.%m.%d"
  manage_template = true
  template_name = "telegraf"
  overwrite_template = false

  health_check_interval = "10s"
  health_check_timeout = "5s"

  tls_ca = "/etc/telegraf/es-ca.pem"
  # insecure_skip_verify = false

If the cluster is genuinely slow to respond to health checks (large cluster, heavy load), relax the interval/timeout rather than disabling the check:

  health_check_interval = "30s"
  health_check_timeout = "10s"
  # health_check_interval = "0s"   # disables the check entirely — last resort only

Then confirm the cluster itself is healthy; a red status means the output has no node to write to no matter how Telegraf is configured:

curl -sS -u "${ES_USER}:${ES_PASSWORD}" https://10.0.0.30:9200/_cluster/health?pretty | grep '"status"'

Example Root Cause Analysis

After enabling security on an Elasticsearch cluster, a Telegraf host began logging [outputs.elasticsearch] Error in plugin: health check timeout: no Elasticsearch node available, and dashboards fed from that index went stale. nc -z -v 10.0.0.30 9200 succeeded, so the port was open. But curl https://10.0.0.30:9200/_cluster/health returned 401 Unauthorized — the cluster now demanded credentials the Telegraf output did not send, so the health check on /_nodes/http never returned a usable node and Telegraf reported “no node available.”

Adding username = "${ES_USER}" / password = "${ES_PASSWORD}" (and tls_ca for the new private CA) to the output block, then restarting, made the health check pass and documents index on the next flush. The lesson: “no Elasticsearch node available” is frequently an auth or TLS failure at the health-check endpoint, not an unreachable cluster — reproduce /_cluster/health with curl and the real error (401, cert, or timeout) tells you which layer to fix.

Prevention Best Practices

• Reproduce /_cluster/health and /_nodes/http with curl from the Telegraf host so auth/TLS problems surface before deploy.
• Always target the HTTP port (9200) with the correct scheme; never point the output at the transport port (9300).
• Provide username/password from ${ENV_VARS} and tls_ca for private CAs instead of insecure_skip_verify = true.
• Size health_check_interval/health_check_timeout to the cluster’s real latency; overly aggressive values falsely mark nodes unavailable.
• Alert on cluster status; a red cluster will always yield “no node available” until shards recover.
• Manage the index template (manage_template) so mapping conflicts do not fail writes after connectivity is fixed.

Quick Command Reference

# Reachability and the exact endpoints the output uses
nc -z -v 10.0.0.30 9200
curl -sS -u "${ES_USER}:${ES_PASSWORD}" https://10.0.0.30:9200/_cluster/health?pretty
curl -sS -u "${ES_USER}:${ES_PASSWORD}" https://10.0.0.30:9200/_nodes/http?pretty | head

# Watch the elasticsearch output health check + writes
telegraf --config /etc/telegraf/telegraf.conf --test-wait 20 --debug 2>&1 | grep -i elasticsearch

# Tail output errors live
journalctl -u telegraf -f | grep -i elasticsearch

Related Guides

• Telegraf writing to outputs: could not write
• Telegraf output context deadline exceeded
• Telegraf x509 certificate signed by unknown authority

More fixes in the Telegraf guides.

Conclusion

[outputs.elasticsearch] health check timeout: no Elasticsearch node available means the output’s node health check found no usable node before timing out — usually a wrong URL/port, an unhealthy cluster, or an auth/TLS failure at the health endpoint. Reproduce /_cluster/health with curl from the Telegraf host to see whether it is a hang (network/down), a 401 (auth), or a cert error (TLS), then fix urls, username/password, tls_ca, or health_check_interval accordingly. Once the health check passes against a healthy cluster, metrics index reliably.