Policy managed index stuck on Evaluating transition conditions

OpenSearch
1

Versions: Opensearch v 2.19.3

Describe the issue: Index policy is stuck in Running state. Message: Evaluating transition conditions [ index name ].
And the most recent index is stuck on Rollover action “Missing alias or not the write index when rollover [index=smarthome-release-mts-2026-05]”

My objective: Configure Index management policy properly to implement the following workflow: Hot index → Warm index (older 7 days) → Cold index (older 30 days, read-only) → S3 (older 90 days, move index to S3 repo and clean node disk space) → Delete (older 365 days, delete from S3).

Configuration: My agents send logs to Logstash server, where filter chain confugured to put logs in relevant index based on month of year and my conditions:

filter {
if [Project] == “Smarthome” and “mts” in [Profile] {
mutate { add_field => { “[@metadata][target_index]” => “smarthome-%{[Profile]}-%{+yyyy-MM}” } }
}
…
…
}

This part works properly.

On Opensearch’s side I have the following configuration:
1) Template “ism_template”:

ism_template

{
“index_patterns”: [
“smarthome-release-*”
],
“template”: {
“settings”: {
“index.refresh_interval”: “3s”,
“index.number_of_shards”: “10”,
“index.number_of_replicas”: “1”,
“index.plugins.index_state_management.rollover_alias”: “smarthome-release”
},
“aliases”: {
“smartpay-home”: {}
}
},
“composed_of”: [],
“priority”: “0”,
“_meta”: {
“flow”: “simple”
},
“name”: “ism_template”
}

2) Alias “smarthome-release”.
3) State management policy “smarthome-stage-hot-warm-cold-delete”:

smarthome-stage-hot-warm-cold-delete policy:

{
“id”: “smarthome-prod-hot-warm-cold-delete”,
“seqNo”: 229987468,
“primaryTerm”: 114,
“policy”: {
“policy_id”: “smarthome-prod-hot-warm-cold-delete”,
“description”: “smarthome release logs lifecycle policy”,
“last_updated_time”: 1776926824554,
“schema_version”: 21,
“error_notification”: null,
“default_state”: “hot”,
“states”: [
{
“name”: “hot”,
“actions”: [
{
“retry”: {
“count”: 3,
“backoff”: “exponential”,
“delay”: “1m”
},
“alias”: {
“actions”: [
{
“add”: {
“aliases”: [
“smarthome-release”
]
}
}
]
}
},
{
“retry”: {
“count”: 3,
“backoff”: “exponential”,
“delay”: “1m”
},
“rollover”: {
“min_index_age”: “7d”,
“copy_alias”: false
}
}
],
“transitions”: [
{
“state_name”: “warm”
}
]
},
{
“name”: “warm”,
“actions”: [
{
“retry”: {
“count”: 3,
“backoff”: “exponential”,
“delay”: “1m”
},
“replica_count”: {
“number_of_replicas”: 1
}
}
],
“transitions”: [
{
“state_name”: “cold”,
“conditions”: {
“min_index_age”: “30d”
}
}
]
},
{
“name”: “cold”,
“actions”: [
{
“retry”: {
“count”: 3,
“backoff”: “exponential”,
“delay”: “1m”
},
“read_only”: {}
}
],
“transitions”: [
{
“state_name”: “s3”,
“conditions”: {
“min_index_age”: “90d”
}
}
]
},
{
“name”: “s3”,
“actions”: [
{
“timeout”: “3h”,
“retry”: {
“count”: 7,
“backoff”: “exponential”,
“delay”: “1m”
},
“snapshot”: {
“repository”: “spcom-s3-repository”,
“snapshot”: “smarthome-release-s3-snap”
}
}
],
“transitions”: [
{
“state_name”: “delete”,
“conditions”: {
“min_index_age”: “365d”
}
}
]
},
{
“name”: “delete”,
“actions”: [
{
“retry”: {
“count”: 3,
“backoff”: “exponential”,
“delay”: “1m”
},
“delete”: {}
}
],
“transitions”:
}
],
“ism_template”: [
{
“index_patterns”: [
“smarthome-release-*”
],
“priority”: 100,
“last_updated_time”: 1666265175863
}
]
}
}

4) Attached and tested S3 repository “spcom-s3-repository”.

Relevant Logs or Screenshots:

tail -f -n 300 /opt/opensearch/logs/opensearch.log | grep smarthome-release
[2026-05-03T09:26:15,587][INFO ][o.o.j.s.JobScheduler ] [opensearch-node1] Will delay 37077 miliseconds for next execution of job smarthome-release-mts-2026-04
[2026-05-03T09:26:16,342][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Executing attempt_transition_step for smarthome-release-mts-2026-04
[2026-05-03T09:26:16,343][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Finished executing attempt_transition_step for smarthome-release-mts-2026-04
[2026-05-03T09:26:59,908][INFO ][o.o.j.s.JobScheduler ] [opensearch-node1] Will delay 151781 miliseconds for next execution of job smarthome-release-mts-2026-01
[2026-05-03T09:27:00,601][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Executing attempt_transition_step for smarthome-release-mts-2026-01
[2026-05-03T09:27:00,604][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Finished executing attempt_transition_step for smarthome-release-mts-2026-01
[2026-05-03T09:27:24,701][INFO ][o.o.j.s.JobScheduler ] [opensearch-node1] Will delay 53626 miliseconds for next execution of job smarthome-release-mts-2026-02
[2026-05-03T09:27:25,368][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Executing attempt_transition_step for smarthome-release-mts-2026-02
[2026-05-03T09:27:25,368][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Finished executing attempt_transition_step for smarthome-release-mts-2026-02
[2026-05-03T09:27:29,180][INFO ][o.o.j.s.JobScheduler ] [opensearch-node1] Will delay 145477 miliseconds for next execution of job smarthome-release-mts-2025-12
[2026-05-03T09:27:29,634][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Executing attempt_transition_step for smarthome-release-mts-2025-12
[2026-05-03T09:27:29,634][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Finished executing attempt_transition_step for smarthome-release-mts-2025-12
[2026-05-03T09:27:32,747][INFO ][o.o.j.s.JobScheduler ] [opensearch-node1] Will delay 168770 miliseconds for next execution of job smarthome-release-mts-2026-03
[2026-05-03T09:27:33,767][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Executing attempt_transition_step for smarthome-release-mts-2026-03
[2026-05-03T09:27:33,768][INFO ][o.o.i.i.ManagedIndexRunner] [opensearch-node1] Finished executing attempt_transition_step for smarthome-release-mts-2026-03

image
image1621×446 85.3 KB

It seems I have some misconfigurations to make the desired lifecycle work properly.

Could anyone help me configure Policy and Index template properly please?

2

:frowning: nobody can help?(

3

@wh1test It would appear you have 2 issues with the above config:

Problem 1: Alias action missing is_write_index

The ISM alias action in hot state needs "is_write_index": true:

{"alias": {"actions": [{"add": {"alias": "smarthome-release", "is_write_index": true}}]}}

Problem 2: Fundamental design conflict

Logstash creates a fresh date-named index every month. Even if rollover succeeds on mts-2026-05, next month Logstash creates mts-2026-06 without the alias, and the cycle repeats. ISM rollover is designed for continuous numbered indices (000001->000002), not monthly date-named buckets.

The right fix for your use case is to drop rollover entirely: Logstash already does the partitioning. You just need age-based transitions:

"hot": {
  "actions": [],
  "transitions": [{"state_name": "warm", "conditions": {"min_index_age": "7d"}}]
}

Remove the rollover and alias actions from hot entirely. warm → cold at 30d, cold → s3 at 90d, s3 → delete at 365d stays as-is.

Hope this helps