A plain-language definition before we get into any mechanics.

Rollover is a feature in Elasticsearch that automatically creates a new index and switches ongoing writes to it once the current index meets a defined condition, such as growing too large, holding too many documents, or getting too old. Rather than one index growing forever, rollover produces a sequence of indices over time, with only the most recent one actively receiving new data at any given moment.

The “label on the shelf” in this analogy is a real Elasticsearch feature called an alias. Applications never write directly to a specific rollover-generated index by name; they write to a stable alias, and rollover’s job is to move that alias’s write pointer from the old, full index to the newly created one at exactly the right moment.

It is worth being precise about what rollover does and does not do, since the name can suggest more than the feature actually delivers on its own. Rollover itself only performs one action: check a condition, and if it is met, create a new index and switch the write alias. It does not, by itself, delete old data, move it to cheaper storage, or reduce its resource footprint — those are separate, related capabilities that are commonly paired with rollover but are not part of what the word “rollover” strictly refers to.

Understanding what breaks without rollover explains why the feature exists at all.

Many real-world Elasticsearch use cases involve a continuous stream of new data: application logs, monitoring metrics, security events, or e-commerce order records. If every one of these events is written into a single index forever, that index inevitably grows without bound, and Elasticsearch’s performance characteristics start to degrade in several compounding ways as it does.

A single oversized index also becomes an operational liability in ways beyond raw performance. Deleting old data requires expensive delete-by-query operations rather than a simple index removal. Adjusting the number of shards for better performance requires a costly reindex of the entire dataset. And a single very large index concentrates risk: if something goes wrong with it, the blast radius covers the entire dataset rather than a smaller, time-bounded slice of it.

There is also a subtler cost worth naming: an ever-growing single index makes capacity planning far harder than a rollover-managed sequence does. With rollover, the size and growth rate of the most recent index gives a clear, current signal for how much resource a given time period of data actually requires, which can be used directly to forecast future needs. A single monolithic index blends every historical period’s growth pattern together, making it much harder to tell whether recent growth reflects a genuine, ongoing trend or a one-time historical spike buried somewhere in the accumulated total.

Rollover addresses every one of these issues at once by naturally slicing continuous data into a sequence of smaller, time- or size-bounded indices, each of which can be searched, managed, and eventually deleted independently of the others.

It is also worth noting that this problem rarely announces itself with an obvious failure. Teams often discover an oversized index only indirectly — a dashboard that used to load instantly starts taking several seconds, or a routine cleanup job that used to finish quickly starts timing out — long after the underlying index has already grown well past the point where rollover, applied from the start, would have kept things manageable. This delayed, indirect symptom pattern is part of why rollover is best adopted proactively, before an existing index becomes a problem, rather than reactively once it already is one.

A working rollover configuration is built from a small number of consistent pieces.

Together, these pieces describe a self-sustaining cycle: an index template defines what every new index should look like, the write alias gives applications one stable place to send data, and the rollover conditions decide exactly when the current index is retired in favor of a freshly created one using the naming pattern.

It is worth walking through what happens if any single piece of this setup is missing or misconfigured, since each plays a distinct, non-substitutable role. Without a matching index template, new indices are created with default, likely incorrect settings, since rollover has no other source of mapping information to draw from. Without a consistent naming pattern, the sequence of generated index names can become unpredictable, making it harder to reason about which index corresponds to which time period. Without a write alias — using a plain index name instead — rollover cannot run at all, since there is no stable pointer for it to redirect.

The index template deserves particular attention because it is the piece most likely to be forgotten during initial setup, yet it has consequences that compound with every single rollover afterward. If the template is missing a field mapping, or defines a setting differently than intended, every new index rollover creates inherits that same gap or inconsistency, silently multiplying a single mistake across the entire future sequence of indices rather than confining it to one.

Rollover rarely operates alone — it is usually one stage within a broader automated lifecycle.

At its core, rollover is a single, well-defined operation: given an alias and a set of conditions, check whether the alias’s currently pointed-to index satisfies any condition, and if so, create a new index and move the alias to it. Index Lifecycle Management, often used alongside rollover, wraps this single operation inside a broader, ongoing policy that also governs what happens to an index after it stops receiving writes — shrinking it, moving it to cheaper storage, or eventually deleting it.

graph TD
    A[Write Alias: logs-write] --> I1[logs-000001]
    A -.rollover triggers.-> I2[logs-000002]
    A --> I2
    I1 -.no longer receives writes.-> I1
    R[Read Alias: logs-read] --> I1
    R --> I2
        

This separation of concerns — rollover deciding when to switch, ILM deciding what happens next — is what allows Elasticsearch to support a full data lifecycle without any single feature needing to understand the whole picture. Rollover only needs to know about the alias and its conditions; it has no awareness of what eventually happens to an index once it is no longer being written to, and it does not need to.

This architectural boundary also explains why rollover integrates so cleanly with Index Lifecycle Management’s later stages. Once rollover has switched the write alias away from an index, that index is guaranteed to be read-only for the remainder of its life under the same policy, which is precisely the stable, unchanging state that operations like shrinking or moving data to cheaper storage require in order to run safely — those later stages simply would not be safe to perform on an index that might still be actively receiving writes.

Here is the sequence of steps Elasticsearch performs when a rollover actually executes.

sequenceDiagram
    participant App as Application
    participant ES as Elasticsearch
    participant Alias as Write Alias
    App->>ES: Index a document via alias
    ES->>ES: Check rollover conditions on current index
    alt Condition met
        ES->>ES: Create new index from template
        ES->>Alias: Switch write pointer to new index
        ES-->>App: Rollover performed, document written to new index
    else Condition not met
        ES-->>App: Document written to current index as usual
    end
        

It is worth noting what does not change during this process: the old index’s shard allocation, its replica count, and every document already indexed within it remain exactly as they were before rollover ran. Rollover’s entire effect on the previous index is simply removing its write designation — a small, surgical change with no impact on the data already stored there, which is part of what makes rollover such a low-risk operation to run frequently and automatically.

Rollover conditions are not monitored continuously in the background by default — they are checked at specific moments.

A manually invoked rollover check happens on demand, whenever an explicit rollover request is issued against the alias, at which point Elasticsearch immediately evaluates the current index against the configured conditions. When rollover is instead managed through an Index Lifecycle Management policy, this check happens automatically on a periodic interval, without any external trigger being required.

flowchart LR
    T[Periodic ILM Check or Manual Trigger] --> C{Any condition met?}
    C -->|max_age exceeded| Y[Perform rollover]
    C -->|max_docs exceeded| Y
    C -->|max_size exceeded| Y
    C -->|none exceeded| N[No action, continue writing]
        

It is worth being precise about the “any one” logic shown above: when multiple conditions are configured together, rollover is triggered the moment the first one is satisfied, not only once every configured condition is simultaneously true. This means conditions function as independent safety thresholds rather than a combined requirement, and the practical effect is that whichever condition is reached first, in real usage, ends up being the one that actually governs how often rollover happens.

This variability is not a flaw to be engineered away — it is precisely the point of combining conditions in the first place. A team that only cares about strict calendar alignment can configure a single age-based condition and accept that a traffic spike might occasionally produce an oversized index before the next scheduled rollover. A team that prioritizes protecting shard performance above all else can instead rely primarily on a size-based condition and accept that rollover frequency will fluctuate with traffic. Most production setups land somewhere between these two extremes, accepting some timing variability in exchange for protection against both kinds of failure.

These three operations are often mentioned in the same breath but solve entirely different problems.

These three operations frequently appear together in a single lifecycle policy: rollover creates the sequence of indices, shrink later reduces the shard count of each index once it becomes read-only to reclaim resources, and reindex is reserved for the separate, less frequent scenario where an existing index’s data needs to be restructured under a different mapping altogether.

Confusing these three operations tends to happen most often around shrink, since it can feel similar to rollover at a glance — both operations touch an index’s shard structure in some sense. The key distinction is timing and purpose: rollover happens continuously, at the boundary between an old write target and a new one, while shrink happens once, after an index has already stopped being written to, purely to reduce its resource footprint now that its shard count no longer needs to support active write throughput.

A small set of condition types covers the vast majority of real rollover configurations.

Choosing which conditions to configure, and their thresholds, is really a question of what failure mode a team is most trying to avoid. A maximum age condition guarantees a predictable, calendar-aligned rollover cadence useful for compliance or reporting boundaries. A maximum size or primary shard size condition instead protects against any single shard growing so large that it starts to hurt search and indexing performance, regardless of how quickly or slowly time passes.

Maximum document count, the remaining condition type, tends to matter most for data where document size varies dramatically, since a size-based threshold alone might allow either a huge number of small documents or a small number of huge documents to accumulate before triggering, both of which can create their own distinct performance characteristics worth bounding independently of raw storage size.

The distinction between maximum size and maximum primary shard size deserves its own moment of attention, since the two are easy to conflate but behave quite differently once an index has more than one primary shard. Maximum size looks at the combined footprint of every primary shard added together, while maximum primary shard size looks specifically at whichever single shard is largest, which matters because search and indexing performance problems tend to trace back to individual oversized shards rather than an index’s aggregate size alone.

Rollover solves real operational problems, but it introduces its own set of considerations.

It is worth framing this trade-off honestly: rollover trades the single, simple problem of “one index grows forever” for the somewhat more distributed problem of “many indices need to be tracked and eventually cleaned up.” This is almost always a favorable trade, since the second problem is far easier to automate reliably than the first, but it is a trade, not a free win — a rollover setup with no attached retention policy has genuinely not finished solving the original problem, only relocated part of it.

A handful of patterns cover most real rollover deployments, and a handful of anti-patterns explain most of the pain teams run into.

A handful of habits separate a smoothly operating rollover setup from a fragile one.

A related, less obvious version of this mistake is setting thresholds so low that rollover fires far more often than intended, producing a large number of very small indices in a short period. This carries its own cost, since every index — however small — still consumes some baseline cluster resources for its shard structure and metadata, meaning an overly aggressive rollover configuration can end up hurting cluster health in a different way than the problem it was meant to solve.

It is also worth developing a habit of periodically spot-checking a handful of rolled-over indices from different points in the past, rather than assuming the first successful rollover guarantees every subsequent one behaved identically. Configuration drift — a template updated for one reason, a cluster setting changed for another — can subtly affect later rollovers in ways that are easy to miss without occasionally revisiting older generations of the sequence.

A healthy rollover setup is one that is actively watched, not simply configured once and forgotten.

It is also worth distinguishing monitoring rollover’s own health from monitoring the broader cluster’s health, since the two can diverge. A cluster can appear entirely healthy by every standard metric while a specific rollover-managed alias has quietly stopped rolling over correctly — perhaps because a template error prevents new index creation — meaning the current write index keeps growing well past its intended bound even as every other part of the cluster looks completely normal.

Rollover interacts with a few access-control and operational-safety concerns worth naming explicitly.

Because rollover-managed retention often doubles as a compliance mechanism — ensuring data older than a required retention window is reliably deleted — any process that could interfere with rollover or its associated lifecycle policy, whether accidentally or maliciously, deserves the same scrutiny as any other control governing regulated data retention.

It is also worth considering the audit trail implications of alias switching itself. Because the write alias’s target changes over time, any security investigation that needs to reconstruct “where was this specific document actually written, and when” benefits from logging or retaining rollover events themselves — not just the documents — so that the mapping between a point in time and the specific index that was active at that moment remains reconstructable well after the fact.

Rollover shows up constantly across industries wherever continuous data streams meet the need for manageable indices.

Across every one of these examples, the underlying motivation is the same: continuous data has no natural stopping point, and rollover supplies the missing structure, slicing an endless stream into manageable, independently retained segments without ever requiring the writing application to think about it.

It is also worth noting what these examples do not have in common: their rollover conditions, retention windows, and shard sizing all differ significantly based on data volume, regulatory requirements, and query patterns specific to each domain. There is no single universally correct rollover configuration — the right thresholds for a low-volume compliance audit log look nothing like the right thresholds for a high-throughput metrics pipeline, and part of adopting rollover well is resisting the temptation to copy another team’s configuration wholesale without first understanding why those particular thresholds fit their particular data.

A short set of questions that come up repeatedly once teams start configuring rollover in real projects.

No, rollover only creates a new index and redirects writes to it; the previous index remains fully intact and searchable until a separate retention or deletion process removes it.

Yes, a manual rollover request can be issued at any time; if the configured conditions happen to be met it proceeds normally, and some rollover requests can also be configured to force a rollover regardless of whether conditions are currently satisfied.

Rollover triggers as soon as any single configured condition is met, not only when every condition is simultaneously satisfied, so the conditions act as independent thresholds rather than a combined requirement.

No, applications should always write through the stable alias rather than a specific index name, so the alias automatically reflects wherever rollover has most recently pointed it, with no application-side changes required.

Yes, as long as a read alias or wildcard pattern spanning the full sequence of indices is used for searching, queries can seamlessly cover both older, rolled-over indices and the current write index together.

No, rollover is one specific operation — switching to a new index once a condition is met — while Index Lifecycle Management is a broader automated policy that can include rollover as one stage alongside later steps like shrinking or deleting indices.

No, rollover never modifies existing documents or the old index’s mapping; it only affects where new documents are written going forward, leaving already-indexed data completely untouched.

If no condition is ever satisfied, the current index simply continues receiving writes indefinitely, exactly as it would without rollover configured at all — rollover is entirely condition-driven and takes no action unless a threshold is actually crossed.

There is no built-in “undo” for a rollover, since it is really just an index creation plus an alias update; recovering from an unwanted rollover typically means manually moving the write alias back or adjusting subsequent writes, rather than reversing a single dedicated action.

Not necessarily — since each new index is created fresh from the current index template at the time of rollover, a template change can adjust the shard count for future indices in the sequence without affecting the shard count of indices created earlier.

Rollover is the mechanism Elasticsearch provides for turning an otherwise endless stream of incoming data into a manageable sequence of time- or size-bounded indices, automatically creating a new index and redirecting a stable write alias to it once a configured condition — age, document count, size, or primary shard size — is met. Applications never need to know or care which specific index is currently active, since they always write through the alias, and old indices remain fully intact and searchable after rollover, ready to be managed further by a broader lifecycle policy. Used well, rollover turns index management from a manual, reactive chore into a predictable, automated part of how continuous data is handled from the moment it is first written.

The broader principle underlying this guide is one that applies well beyond rollover itself: any system that accepts continuous, unbounded input needs some deliberate mechanism for imposing structure on that input over time, or the structure will eventually be imposed involuntarily, in the form of degraded performance and difficult cleanup. Rollover is Elasticsearch’s specific answer to that principle for indices, and understanding it well — its narrow job, its reliance on aliases, and its need to be paired with a genuine retention strategy — is what separates a data pipeline that stays manageable for years from one that quietly becomes a liability within months.