---
title: Supported version is outdated
description: Describes what AutoOps detects and surfaces with the Supported version is outdated insight: The cluster runs an Elasticsearch version that is not maintained any more but is still eligible to get support.
url: https://www.elastic.co/docs/reference/autoops-insights/elasticsearch/supported_version_is_outdated
products:
  - Elastic Cloud Enterprise
  - Elastic Cloud Hosted
  - Elastic Cloud on Kubernetes
  - Elasticsearch
applies_to:
  - Elastic Cloud Hosted: Generally available
  - Elastic Cloud on Kubernetes: Generally available
  - Elastic Cloud Enterprise: Generally available
  - Self-managed Elastic deployments: Generally available
---

# Supported version is outdated
The cluster runs an Elasticsearch version that is not maintained any more but is still eligible to get support. Newer releases include performance improvements, stability fixes, and security patches.
<note>
  For a complete list of insights, refer to [AutoOps insights](https://www.elastic.co/docs/reference/autoops-insights/elasticsearch).
</note>


## Insight details


| Field     | Value           |
|-----------|-----------------|
| Component | Elasticsearch   |
| Severity  | Medium          |
| Scope     | Cluster         |
| Domains   | version-upgrade |


## Example: What you might see in AutoOps

The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.

### A newer Elasticsearch version is available


#### What was detected

The cluster runs 8.15.0. The recommended version is 9.5.0.
The following open events are known to stall or fail upgrades. Resolve them before you upgrade. That list is not exhaustive.
- Disk watermark flood stage
- Deployment not highly available

[Inspect open events](https://cloud.elastic.co/deployments/d3pl0yment01?eventTypes=DISK_WATERMARK_FLOOD_STAGE,CLUSTER_NOT_HA)

#### Recommendations

<note>
  AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
</note>

<dropdown title="Resolve open events before you upgrade">
  **Condition**: Shown when upgrade-related events are open.These open events are known to stall or fail upgrades. Open the list and resolve each event before you upgrade. Also review Watcher, old system indices, and the other preparation steps in the [upgrade guide](https://docs-demo.elastic.dev/docs/deploy-manage/upgrade/plan-upgrade).[Inspect open events](https://cloud.elastic.co/deployments/d3pl0yment01?eventTypes=DISK_WATERMARK_FLOOD_STAGE,CLUSTER_NOT_HA)
</dropdown>

<dropdown title="Temporary upgrade recovery limit increase">
  **Condition**: Shown when none of the recovery-pressure related events are open (CPU, heap, disk watermarks, or high cluster pending tasks).Raise `cluster.routing.allocation.node_concurrent_recoveries` temporarily for the rolling upgrade, starting at 8 (the Elasticsearch default is 2). AutoOps shows this action only while CPU, heap, disk watermark, and pending-task insights are not open. If those insights open after you raise the limit, stop increasing it. Restore the transient setting with `PUT null` after the upgrade.If shard movement itself is slowing the plan, you might also raise `cluster.routing.allocation.cluster_concurrent_rebalance` temporarily and restore it after the upgrade. If the cluster has unreplicated indices on included tiers, also raise `cluster.routing.allocation.node_initial_primaries_recoveries` so missing primaries can reopen faster after a node restarts. Avoid aggressive increases on slow disks or similar storage.If a node might stay down longer than `index.unassigned.node_left.delayed_timeout`, review [delayed allocation](https://docs-demo.elastic.dev/docs/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/delaying-allocation-when-node-leaves) so shards do not start moving unnecessarily during the upgrade.To restore the temporary settings after the upgrade, send `null` for the transient keys that you changed.
  ```json

  {
    "transient": {
      "cluster.routing.allocation.node_concurrent_recoveries": 8
    }
  }
  ```

  <note>
    Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>

<dropdown title="Upgrade Elasticsearch">
  **Condition**: Always shown for this insight.Upgrade to the latest minor of your current major before moving to 9.5.0.
  - [Plan your upgrade](https://docs-demo.elastic.dev/docs/deploy-manage/upgrade/plan-upgrade)
  - [Upgrade Assistant](https://docs-demo.elastic.dev/docs/deploy-manage/upgrade/prepare-to-upgrade/upgrade-assistant)
  - [Troubleshoot upgrades](https://docs-demo.elastic.dev/docs/troubleshoot/elasticsearch/troubleshooting-upgrades)
</dropdown>


#### Background and impact

Keeping Elasticsearch up to date on the latest maintained minor ensures the cluster benefits from security patches, bug fixes, and performance improvements that older releases do not receive. Newer releases also include storage and efficiency work, such as better compression, that can reduce the resources a cluster needs for the same workload. Versions still in support have a defined end-of-life date; planning the upgrade now avoids time pressure when the version reaches that boundary.

## Guide

[Plan upgrade](https://docs-demo.elastic.dev/docs/deploy-manage/upgrade/plan-upgrade)