Elasticsearch Index Templates

Some systems create new indexes all the time. A logging setup might start a fresh index every day, such as logs-2026.11.04. Typing the same settings and mappings for each one wastes effort and invites mistakes. An index template stores those rules once and applies them automatically whenever a matching index appears.

Think of a template as a cookie cutter. Each new index comes out with the same shape, no matter who creates it or when.

How a Template Matches an Index

Every template lists one or more name patterns. When a new index is created, Elasticsearch compares its name against all patterns and applies the best match.

Template "logs-template"
  pattern: logs-*
  settings: 1 shard, 1 replica
  mappings: timestamp (date), message (text), level (keyword)

New index created: logs-2026.11.04
        │
        ▼
Name matches "logs-*"  ──→  Template rules applied automatically
        │
        ▼
Index ready with the right settings and mappings

Creating a Composable Template

Elasticsearch 7.8 introduced composable templates, and they are the current standard. The block below defines a complete template in one request.

PUT /_index_template/logs-template
{
  "index_patterns": ["logs-*"],
  "priority": 100,
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    },
    "mappings": {
      "properties": {
        "timestamp": { "type": "date" },
        "message":   { "type": "text" },
        "level":     { "type": "keyword" },
        "service":   { "type": "keyword" }
      }
    }
  }
}

Create any index that starts with logs- and the settings and mappings arrive without extra work. A quick check with GET /logs-2026.11.04 confirms it.

Component Templates

Large setups repeat the same blocks across many templates. Component templates hold reusable pieces, and an index template combines them like building blocks.

PUT /_component_template/shared-settings
{
  "template": {
    "settings": { "number_of_shards": 1, "number_of_replicas": 1 }
  }
}

PUT /_component_template/shared-mappings
{
  "template": {
    "mappings": {
      "properties": { "timestamp": { "type": "date" } }
    }
  }
}

PUT /_index_template/app-template
{
  "index_patterns": ["app-*"],
  "composed_of": ["shared-settings", "shared-mappings"],
  "priority": 200
}

  [shared-settings]  ┐
                     ├──→ [app-template] ──→ app-2026.11.04
  [shared-mappings]  ┘

Change a component once, and every template that uses it picks up the change for future indexes.

Priority and Overlapping Patterns

Two templates can match the same index name. Elasticsearch applies only the template with the highest priority number. Overlapping patterns with equal priority cause an error, so give each template a distinct number.

Template	Pattern	Priority	Winner for "logs-app-01"
general-logs	logs-*	100	No
app-logs	logs-app-*	200	Yes

Testing Before Creating

The simulate API shows which settings and mappings an index name would receive. Use it to catch pattern mistakes before real data arrives.

POST /_index_template/_simulate_index/logs-2026.11.05

The response lists the final settings, mappings, and the templates that contributed.

Rules Worth Remembering

Templates affect only indexes created after the template exists. Existing indexes keep their old settings. Settings in the create-index request override the template, so a manual request can still pick a different shard count. Template changes never rewrite old data.

Task	Request
List templates	GET /_index_template
View one template	GET /_index_template/logs-template
Delete a template	DELETE /_index_template/logs-template
List components	GET /_component_template

Older tutorials show legacy templates created with PUT /_template. Those still work in version 8 but carry a deprecation notice. New projects should use composable templates.

A Real Scenario

A company runs ten services, and each service writes its own daily index. Without templates, a new engineer who creates an index by hand might forget the date mapping. Elasticsearch guesses the field type from the first document, and a timestamp stored as plain text breaks every time-based chart in Kibana.

A template removes the guesswork. The rule lives in one place, and every service inherits it. Reviewers read one template instead of hunting through ten services for differences.

Without a template:

  service-a-2026.11.04   timestamp: text   ✘
  service-b-2026.11.04   timestamp: date   ✔
  service-c-2026.11.04   timestamp: text   ✘

With a template:

  service-a-2026.11.04   timestamp: date   ✔
  service-b-2026.11.04   timestamp: date   ✔
  service-c-2026.11.04   timestamp: date   ✔

Common Mistakes

Pattern typos top the list. A template for "log-*" never matches an index named "logs-2026," and the failure stays invisible until someone checks the mapping. The simulate API catches this mistake in seconds.

Forgetting priority causes the next problem. Two templates with overlapping patterns and equal priority trigger an error at creation time, and a lower-priority template can hide behind a broader one. Assign priorities in clear ranges, such as 100 for general rules and 200 for specific rules.

Expecting retroactive changes disappoints many beginners. A template edit never touches existing indexes. Reindex old data into a new index when the old data needs the new rules.