How do you verify which Elasticsearch template will apply to an index before it is created?

## The gap simulate closes An index template is evaluated exactly once, when an index is created, and the result is silent. If your `index_patterns` has a typo, nothing errors — the index is simply created with defaults and dynamic mapping. If another team's template outranks yours on priority, nothing errors either — the index is created with their configuration. Both failures are only visible in the mapping of an index that already exists, at which point the field types are frozen and the remedy is a reindex. The simulate APIs exist to move that discovery earlier, to the moment you are editing the template. ## _simulate_index — "what will this name get?" `POST _index_template/_simulate_index/<index-name>` is the diagnostic workhorse. You give it an index name; the name does not have to exist and usually should not. Elasticsearch does the full resolution: 1. finds every index template whose `index_patterns` match the name, 2. selects the winner by `priority`, 3. merges the winner's `composed_of` components in order, then its own `template` block, 4. returns the composed `settings`, `mappings` and `aliases`. Alongside the composed result it returns an `overlapping` array: the other templates that matched the name, each with its `index_patterns`. That section is the answer to "why did my template not apply?" — if your template's name is in `overlapping` rather than being the one that produced the composed result, it lost the priority contest, and you now know exactly to whom. Because it accepts a name rather than a template, this endpoint is the right call before a rollover: simulate the next backing index name and confirm it will come out the way you expect. ## _simulate — "what does this template compose to?" `POST _index_template/_simulate/<template-name>` composes a stored template and returns the result. More usefully, you can `POST _index_template/_simulate` with a template definition **in the body**, which composes a template you have not stored yet — including the effect of any `composed_of` components that do exist. That is the pre-merge review tool: paste the proposed template, see the mapping it will produce, and attach the output to the change request. Note the difference in what each answers. `_simulate` tells you what one template composes to. It does **not** tell you whether that template would actually win for a given index name; only `_simulate_index` runs the priority contest. ## After the fact Once an index exists, simulate is no longer the tool — the index's own metadata is authoritative and may differ from any template, because a create-index request body can override the whole stack and because settings can be changed on a live index afterwards. Use `GET /<index>/_mapping` and `GET /<index>/_settings` for what an index really has, and reserve simulate for what an index *would* get. Comparing the two is itself a useful drift check: if a long-lived index disagrees with the simulate output for its own name, someone overrode the template or updated the index directly. To see the inputs rather than the outputs, `GET _index_template` and `GET _component_template` list the stored definitions, including each template's `priority`, `version` and `_meta`, and both accept a name pattern (`GET _index_template/logs*`) so you can survey a namespace quickly. ## Making it a gate rather than a habit The strongest version of this practice is automated. Templates live in version control as JSON; a pipeline applies them to a disposable or staging cluster, calls `_simulate_index` for each index name pattern the system actually creates, and diffs the composed mapping against a checked-in golden file. A change that silently drops a field, flips `keyword` to `text`, or gets outranked by a newly installed integration template fails the build instead of failing production. Because the composed output is deterministic and version-controlled, the diff also becomes the review artefact: reviewers read the effective mapping, which is what they care about, rather than trying to simulate a multi-layer merge in their heads.