Elasticsearch End of Life: Dates by Version and Support Options

Elasticsearch 7.17 is past end of life: Elastic ended maintenance on 15 April 2025 and support on 15 January 2026. Elasticsearch 8.x reaches end of maintenance on 15 January 2027 and end of support on 15 July 2027. Elasticsearch 9.x is the current major, maintained until at least 15 October 2027. Anything older than 7.17 is unsupported.

Support for those versions comes from Elastic through a subscription, for self-managed clusters and Elastic Cloud, from the community for unsubscribed users, and from independent providers for versions past Elastic's maintenance window, OpenSearch, and the cluster operations that vendor support does not take on.

How long Elastic maintains a version

Elastic's end of life policy maintains each major release for the longer of 30 months from general availability or 18 months from the general availability of the next major release. Within that, Elastic maintains the most recent two minor releases of the current major and the final minor release of the previous major. Staying supported therefore means staying on a recent minor, not just the right major.

At the time of writing, Elasticsearch 7.17 reached end of maintenance on 15 April 2025 and end of support on 15 January 2026. The 8.x line reaches end of maintenance on 15 January 2027 and end of support on 15 July 2027. A great many production clusters are still on 7.x.

Elasticsearch end of life dates by version

Dates from Elastic's end of life page, read on 4 October 2026. The same dates apply to Kibana, Logstash, Elastic Agent and Beats in the same release line.

Within 8.x, Elastic notes that 8.17 is maintained until the release of 8.19 and 8.18 until the release of 9.2, so an 8.x cluster can be inside the major's window and still on an unmaintained minor. Elastic Enterprise Search is a retired product: its 8.x line ends maintenance on 15 January 2027 and support on 15 July 2027, with no further major releases.

End of maintenance vs end of support

The two dates mean different things. End of maintenance is when Elastic stops shipping bug fix and security releases for the version. End of support, six months later for a major release, is when Elastic's support team stops assisting with it. In the gap, a subscriber still gets help, but Elastic is not obliged to fix the version and may ask you to upgrade. For a security team, the first date is the one that matters: after it, a new CVE in your version stays open.

What a subscription covers

An Elastic subscription gives you technical support from Elastic for the Elastic Stack, with response targets that depend on the subscription level, and it applies to supported versions and configurations. Without a subscription, help is the documentation and the community forum. Elastic Cloud customers get support as part of the service.

Licensing, and the OpenSearch route

An end of life upgrade is also a licensing decision. In 2021 Elastic moved Elasticsearch and Kibana from Apache 2.0 to a choice of SSPL or the Elastic License 2.0, and in 2024 added the OSI-approved AGPLv3 as a third option. Upgrading a 7.x cluster to 8.x or 9.x means accepting one of those three licenses; for most self-hosted, internal use that changes nothing in practice, but legal teams sometimes ask.

OpenSearch is the Apache 2.0 licensed fork of Elasticsearch 7.10.2, now a Linux Foundation project. Elastic does not support it. Amazon supports its own managed OpenSearch Service. For self-managed OpenSearch, support is the community or an independent provider.

The Elasticsearch incidents that actually page people

• Red or yellow cluster state. A node leaves, shards go unassigned, and the cluster does not heal on its own because of disk watermarks, allocation filtering or a replica count the remaining nodes cannot satisfy. The allocation explain API says why. Acting on the answer safely takes experience.
• JVM heap pressure. Old generation garbage collection runs longer and more often, circuit breakers start rejecting requests, and nodes drop out under load. Common causes are too many shards per node, aggregations on high-cardinality fields and fielddata on text fields.
• Oversharding. Daily indices with five primaries each, kept for a year, leave tens of thousands of small shards. Cluster state becomes huge, master nodes struggle and every operation slows. The fix is index lifecycle management, rollover by size, and shrinking or reindexing what exists.
• Indexing falls behind. Bulk rejections appear, Logstash or Beats back up, and log data arrives hours late during the incident you needed it for. The bottleneck may be the ingest pipeline, refresh interval, storage, or mappings that index far more fields than anyone queries.
• Snapshots nobody has restored. Snapshot jobs report success for years and the first restore attempt happens during a disaster. Repository permissions, version compatibility and restore time are all discoverable in advance.

Upgrading off an unsupported Elasticsearch version

Elasticsearch supports rolling upgrades within a major and from the last minor of one major to the next, so a 7.x cluster first moves to 7.17, then to 8.x. Indices created two majors back must be reindexed before the jump. The breaking changes that cause trouble are usually not in the server: mapping types were removed, security is on by default from 8.0, and client libraries are version-sensitive, so applications and Kibana dashboards need testing. For a cluster still on 6.x or early 7.x, a parallel new cluster with reindex-from-remote is often safer than upgrading in place. This is also the moment teams weigh OpenSearch, and that decision is easier with someone who supports both.

Where independent Elasticsearch support fits

• Clusters on 7.x or early 8.x minors outside the maintenance window, where an upgrade needs planning because of reindexing, mapping changes or client compatibility.
• Self-managed OpenSearch.
• Cluster operations: yellow and red cluster state, unassigned shards, JVM heap pressure and circuit breakers, oversharding, slow indexing behind Logstash or Beats backpressure, snapshot and restore that has never been tested.
• Architecture: shard sizing, index lifecycle management and retention for the log volumes you actually have.

AceMQ provides 24/7 Elasticsearch support for Elasticsearch, the ELK stack and OpenSearch, with a 15-minute emergency SLA and named senior engineers. Examples: heap pressure support and a yellow cluster state remediation.