Elasticsearch Support Options: Elastic, OpenSearch or Independent

Elasticsearch support 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.

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.

OpenSearch

OpenSearch is the Apache 2.0 licensed fork of Elasticsearch 7.10, 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.