🚨 Filebeat Error: 'index_closed_exception' — Cause, Fix, and Troubleshooting Guide

Overview

A closed Elasticsearch index has its shards released from memory and rejects reads and writes. If Filebeat tries to bulk-write to an index that has been closed, ES rejects the items:

Failed to perform any bulk index operations: 403 Forbidden: {"error":{"type":"index_closed_exception","reason":"closed","index":"filebeat-8.13.0-2026.07.12"}}

Indices get closed to save heap on old data, by an ILM/curator action, or by an operator command. When Filebeat’s write alias or target resolves to a closed index, ingestion for that index stops. The events are retried, not dropped, but they cannot land until the index is reopened or the write target points at an open (usually the current rollover) index.

Symptoms

• index_closed_exception with "reason":"closed" on bulk writes.
• Only writes to a specific date/rollover index fail; newer indices may be fine.
• _cat/indices shows the target index in close status.
• Follows a curator run, an ILM misconfiguration, or a manual _close.

Common Root Causes

• Index manually closed to reclaim heap.
• Curator / automation closing indices by age while still the write target.
• Write alias points at a closed index instead of the current write index.
• ILM rollover misconfigured, leaving Filebeat writing to a closed backing index.
• Restored-but-not-opened snapshot index.

How to diagnose

Find the closed index and confirm what Filebeat writes to:

curl -sk 'https://es01:9200/_cat/indices/filebeat-*?v&h=index,status,health' \
  -u elastic:$ES_PASS
curl -sk 'https://es01:9200/_alias/filebeat-*?pretty' -u elastic:$ES_PASS

Check the ILM state of the data stream/alias:

curl -sk 'https://es01:9200/filebeat-*/_ilm/explain?pretty' -u elastic:$ES_PASS | \
  grep -i 'phase\|action\|step'

Fixes

Reopen the closed index so queued writes can land:

curl -sk -XPOST 'https://es01:9200/filebeat-8.13.0-2026.07.12/_open' \
  -u elastic:$ES_PASS

Fix the automation so the current write index is never closed — exclude the write index from curator/ILM close actions, and use ILM rollover so writes always go to a fresh open index:

# Confirm the write alias resolves to an OPEN index
curl -sk 'https://es01:9200/_cat/aliases/filebeat-*?v' -u elastic:$ES_PASS

If you rely on ILM, ensure the policy’s hot phase uses rollover and only closes in a later phase after the alias has moved on. Restart is not required; Filebeat flushes queued events once the index is open.

What to watch out for

• Never close the current write index — only closed old indices are safe.
• Events are retried, not lost, so reopening recovers the backlog.
• A stale write alias pointing at a closed index is a common ILM misconfiguration.
• Restoring a snapshot leaves indices open by default, but a close action may re-close them.

Related

• Filebeat Error: ‘cluster_block_exception … index read-only / allow delete (api)’
• Filebeat Error Guide: ‘ILM policy not found’
• Filebeat Error Guide: ‘503 Service Unavailable’