Elasticsearch action.auto_create_index Setting

action.auto_create_index controls whether Elasticsearch creates a missing index automatically when a document is written to it. The default permits auto-creation for most names, with system and dot-prefixed indices following their own rules. In production clusters the setting is one of the cheapest safety levers available - locking it down prevents typo-induced index explosions, accidental data fan-out, and unintended mapping creation from a misconfigured client.

  • Default: true (with restrictions on internal indices)
  • Scope: Cluster-wide, dynamic - update via cluster settings API
  • Possible values: true, false, or a comma-separated list of +pattern / -pattern rules

How action.auto_create_index Works

When a write request targets an index that doesn't exist, Elasticsearch consults action.auto_create_index:

Value Behavior
true Auto-create any non-existent index (default)
false Reject the write with index_not_found_exception
"logs-*,metrics-*" Permit auto-create for matching patterns, reject the rest
"+logs-*,-*" Same as above, explicit form - allow logs-*, deny everything else
"+.kibana_*,-*" Allow specific dot-prefixed system indices, deny all others

The patterns are evaluated in order, first match wins. A trailing -* (deny-all) is the recommended terminator for production allow-lists. Wildcards * and ? are supported.

System and built-in indices (with names starting with .) and indices created by Elasticsearch features (Kibana, ILM, Watcher, security) follow their own rules and aren't blocked by action.auto_create_index: false.

Configuring action.auto_create_index

Apply at runtime via cluster settings:

PUT /_cluster/settings
{
  "persistent": {
    "action.auto_create_index": "+logs-*,+metrics-*,-*"
  }
}

Disable entirely:

PUT /_cluster/settings
{
  "persistent": {
    "action.auto_create_index": "false"
  }
}

Reset to default:

PUT /_cluster/settings
{
  "persistent": {
    "action.auto_create_index": null
  }
}

The setting is dynamic. Changes apply to subsequent index requests; existing indices are unaffected.

Scenario Recommended value
Strict production, all indices created explicitly false
Production with controlled write paths and known patterns "+app-*,+logs-*,-*"
Mixed environment, tolerate Kibana/Elastic auto-managed indices "+.*,+app-*,-*"
Development / sandbox true

Pair action.auto_create_index with `action.destructive_requires_name` and ILM-driven data streams to keep index lifecycle under explicit control. Most production index creation should flow through index templates or data stream rollover, not ad-hoc client writes.

Common Pitfalls

  1. Leaving true in production. A typo in a client's index name silently creates a new index with whatever mapping Elasticsearch infers, often expensive to clean up.
  2. Setting false without provisioning the indices the application needs. Writes fail until indices are created manually or via index templates.
  3. Allow-listing too broadly. +log*,-* matches logs-app-2026, loggers, logout-events, etc.
  4. Forgetting that data streams need either matching index templates with data_stream configured or explicit PUT /_data_stream/<name> calls - they don't auto-create from a bare write.

Monitoring Index Sprawl

Periodically audit index count and recent creations:

GET /_cat/indices?v&s=creation.date:desc&h=index,creation.date.string,docs.count,store.size

Prevent action.auto_create_index Misconfiguration with Pulse

Pulse is an AI DBA for Elasticsearch and OpenSearch that tracks action.auto_create_index (default true) together with index creation rate, flagging:

  • Drift between intended pattern lists and what is actually applied via persistent cluster settings
  • Settings that are unsafe for your workload (e.g. true left in place in production, or an allow-list like +log*,-* that unintentionally matches logs-app-2026, loggers, and logout-events)
  • The downstream operational impact: index creation rate, unexpected new indices created by typo-induced client errors, and the cluster-state cost of mapping explosion

When a misconfigured client starts creating indices in a loop, Pulse alerts immediately, names the originating service, and proposes a tightened +pattern,-* allow-list - before the cluster state explodes.

Connect your cluster.

Frequently Asked Questions

Q: What is the default value of action.auto_create_index?
A: The default is true - any write to a non-existent index causes Elasticsearch to auto-create it. System and dot-prefixed indices follow their own rules and aren't affected by changing this value.

Q: How do I prevent Elasticsearch from creating indices automatically?
A: Set action.auto_create_index to false via the cluster settings API. Writes to non-existent indices will then return an index_not_found_exception. Use an explicit allow-list ("+pattern,-*") if you need to permit specific name patterns.

Q: What does the +pattern,-pattern syntax mean in action.auto_create_index?
A: Each item is a rule evaluated in order, first match wins. +pattern allows auto-creation for matching names; -pattern denies it. Use -* at the end to deny everything not explicitly allowed.

Q: Does action.auto_create_index affect data streams?
A: Data streams have their own creation flow via index templates with data_stream configured, or explicit PUT /_data_stream/<name>. Setting action.auto_create_index: false doesn't block data stream creation through those paths.

Q: Can I set action.auto_create_index per index?
A: No, it's a cluster-level setting that governs whether indices can be auto-created at all. For per-index controls, use index templates with explicit names or rely on data stream rollover.

Q: What happens to system indices when action.auto_create_index is false?
A: System indices (Kibana, Watcher, security, ILM history) are managed internally by Elasticsearch and remain auto-creatable even when action.auto_create_index: false. The setting only governs user-facing index names.

Q: What's the best tool to prevent index sprawl from action.auto_create_index?
A: Pulse is built for this. It is an AI DBA for Elasticsearch and OpenSearch that tracks index creation rate against the configured action.auto_create_index pattern, names the client behind each unexpected index, and proposes tightened allow-lists before typo-driven sprawl explodes the cluster state.

Subscribe to the Pulse Newsletter

Get early access to new Pulse features, insightful blogs & exclusive events , webinars, and workshops.

We use cookies to provide an optimized user experience and understand our traffic. To learn more, read our use of cookies; otherwise, please choose 'Accept Cookies' to continue using our website.