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/-patternrules
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.
Recommended Production Configurations
| 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
- Leaving
truein production. A typo in a client's index name silently creates a new index with whatever mapping Elasticsearch infers, often expensive to clean up. - Setting
falsewithout provisioning the indices the application needs. Writes fail until indices are created manually or via index templates. - Allow-listing too broadly.
+log*,-*matcheslogs-app-2026,loggers,logout-events, etc. - Forgetting that data streams need either matching index templates with
data_streamconfigured or explicitPUT /_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.
trueleft in place in production, or an allow-list like+log*,-*that unintentionally matcheslogs-app-2026,loggers, andlogout-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.
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.
Related Reading
- Elasticsearch action.destructive_requires_name Setting: Block wildcard deletes
- Elasticsearch Create Index with Mapping: Explicit index creation
- Elasticsearch Index Templates: Manage index settings centrally
- Elasticsearch cluster.max_shards_per_node: Cluster-wide shard cap
- Elasticsearch Too Many Shards Performance: Symptoms of index sprawl