Elasticsearch index.refresh_interval: Defaults, Tuning, and Tradeoffs

The index.refresh_interval setting controls how often Elasticsearch creates a new searchable segment from the in-memory indexing buffer, making newly indexed documents visible to search. The default is 1s, set to -1 to disable automatic refreshes entirely, or any time value (30s, 5m) to trade visibility latency for indexing throughput. This is the single biggest knob for tuning write-heavy workloads in Elasticsearch.

Key Facts

How the Refresh Operation Works

When a document is indexed, it is added to the in-memory indexing buffer and the translog. The document is not searchable yet - search only sees data in Lucene segments on disk. A refresh flushes the buffer into a new segment and opens it for search. Until the next refresh runs, freshly indexed documents do not appear in queries; this is what "near real-time" means in Elasticsearch's documentation.

Every refresh creates a new segment file. More refreshes means more, smaller segments, which means more merge work later. That is the underlying trade-off: short intervals give faster visibility at the cost of indexing throughput, longer intervals give better throughput at the cost of search lag.

The refresh interval does not affect durability. Durability is governed by the translog, which fsyncs on every request by default regardless of refresh settings.

Configuring refresh_interval

Set on a live index with the Update Index Settings API:

PUT /my-index/_settings
{
  "index": {
    "refresh_interval": "30s"
  }
}

Set at index creation:

PUT /logs-2026-05
{
  "settings": {
    "refresh_interval": "30s",
    "number_of_shards": 2,
    "number_of_replicas": 1
  }
}

Disable refreshes entirely (typical for one-shot bulk loads):

PUT /my-index/_settings
{ "index": { "refresh_interval": "-1" } }

When the load finishes, restore the value and force a refresh so the data becomes visible:

PUT /my-index/_settings
{ "index": { "refresh_interval": "1s" } }
POST /my-index/_refresh

You can also trigger a manual refresh anytime with POST /my-index/_refresh. Frequent manual refreshes carry the same cost as a short auto-refresh interval; do not loop over it from application code.

When to Tune refresh_interval

Common Mistakes and Misuses

1. Setting refresh_interval below 1s. Sub-second values are valid but rarely worth it; they multiply segment count and merge IO.
2. Setting refresh_interval to -1 and forgetting to restore it. New data accumulates in the buffer indefinitely and never becomes searchable. After bulk loads, always set the value back and call _refresh.
3. Tuning refresh_interval as a band-aid for slow indexing. If indexing is slow, look at thread-pool rejections, bulk batch size, and replica count first. Refresh is the second-order tuning knob, not the first.
4. Manually calling _refresh from application code. This negates the throughput benefit of a longer interval. Use ?refresh=wait_for on the indexing request instead if you need read-your-writes semantics.
5. Using a uniform interval across all indices. Different indices have different needs - logs and product catalogs do not want the same value.

Monitoring and Tuning refresh_interval

Getting index.refresh_interval right requires knowing your actual indexing rate, segment count, and search latency. Pulse continuously analyzes those signals across every index in your cluster and recommends a refresh interval based on the workload pattern. Pulse flags indices where refresh is producing pathological segment counts, where -1 was set during a bulk load and never restored, and where the refresh setting is silently capping indexing throughput.

With Pulse's proactive monitoring, refresh-driven problems such as excessive segment creation, runaway merge backlogs, or unnecessary refresh overhead are detected automatically and surfaced with auto-RCA before they degrade search performance.

Frequently Asked Questions

Q: What is the default refresh_interval in Elasticsearch?
A: The default is 1s (one second). That value makes recently indexed documents searchable within one second of being written, which is the basis of Elasticsearch's "near real-time" search claim.

Q: What does setting refresh_interval to -1 do?
A: Setting index.refresh_interval to -1 disables automatic refreshes entirely. New documents remain in the in-memory buffer and the translog and do not become searchable until a manual POST /_refresh is issued or the interval is restored to a positive value.

Q: How does refresh_interval affect indexing throughput?
A: A longer refresh_interval reduces segment creation rate, which reduces merge work and frees CPU and IO for indexing. Doubling the interval from 1s to 2s rarely matters; raising it from 1s to 30s during bulk loads can increase throughput by 30-50% on write-bound clusters.

Q: Is refresh_interval dynamic, or do I have to recreate the index?
A: It is dynamic. Update it with PUT /<index>/_settings on a live index, no restart or recreation needed. The new value takes effect on the next refresh cycle.

Q: Does increasing refresh_interval risk losing data?
A: No. Refresh controls search visibility, not durability. Durability is provided by the translog, which fsyncs on every request by default. Even if Elasticsearch crashes, documents written before the crash are recovered from the translog regardless of refresh settings.

Q: Should different indices have different refresh_interval values?
A: Yes. Real-time search indices want the default of 1s. Log and metric indices typically benefit from 10s to 30s. Cold-tier indices can go higher still. Setting per-index values via index templates is the standard approach.

Q: How is refresh_interval related to near real-time search?
A: "Near real-time" in Elasticsearch refers to the lag between indexing a document and being able to search for it. That lag is bounded by index.refresh_interval. A 1s default means worst-case 1s of visibility lag; a 30s setting means up to 30s of lag.

Related Reading

• What is Elasticsearch Refresh Interval: conceptual background and history.
• Change Refresh Interval: step-by-step instructions for live updates.
• Refresh Interval Too Frequent: symptoms and fix when the interval is set too low.
• Update Index Settings: the API used to change refresh_interval and related settings.
• Create Index with Mapping: set refresh_interval at index creation time.
• Index Translog Durability: the setting that actually controls durability.
• Bulk Indexing Operations Failing: how refresh interactions cause bulk failures.