01
Emergency Incident Response
Red cluster, ingest stalled, or Dashboards down for the team that depends on it. A senior engineer joins a live bridge within 15 minutes with access to diagnose — not an automated ticket acknowledgement.
OpenSearch Support
24/7 OpenSearch Support with a 15-Minute Emergency SLA
Last reviewed by Scott Sternloff
AceMQ supports self-managed OpenSearch and Amazon OpenSearch Service in production — unassigned shards after a blue/green deploy, ISM policies that silently stopped rolling over, fine-grained access control errors nobody can decode, and clients still speaking Elasticsearch 7.10. Every ticket reaches a named senior engineer who knows your cluster.
Support quotes answered within 1 hour, by a senior engineer.
- min emergency SLA
- 15
- across Americas, EMEA, APAC
- 24/7
- enterprise customers
- 160+
- countries served
- 26+
Planning a build, upgrade or migration instead? See AceMQ OpenSearch consulting and services.
Customers
Partners
Incident Triage
OpenSearch problems we fix every week
These are real symptoms from real OpenSearch production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Cluster red or yellow with shards refusing to allocate | The allocation explain API for one unassigned shard. Disk watermarks putting a node into read-only, an allocation awareness attribute no remaining node satisfies, or a shard limit per node are the three answers that cover most cases. | Under 1 hour |
| Elasticsearch clients throw a version error against OpenSearch | Whether compatibility.override_main_response_version is enabled. OpenSearch reports its own version at the root endpoint, and older Elasticsearch clients refuse to talk to anything that is not 7.x — this flag is the bridge while you migrate the client libraries properly. | Under 1 hour |
| Heap above 85% and circuit breakers tripping under dashboard load | The parent and fielddata breaker counters against the queries Dashboards is actually firing. A visualisation aggregating on a high-cardinality keyword will pull a large fielddata structure into heap every refresh. | 1–2 hours |
| ISM policy stopped rolling over — one index growing without bound | The ISM explain endpoint for that index. The policy is usually stuck retrying a step because the rollover alias is missing, the index was created outside the matching template, or the policy was edited without bumping the managed index version. | Under 2 hours |
| Amazon OpenSearch Service stuck in a blue/green deployment | Which configuration change triggered it. Instance type, EBS, node count, and several advanced settings each force a full blue/green migration on the managed service — during which write throughput drops and the cluster cannot take another change until it completes. | Same day |
| 403 security_exception on requests that used to work | Fine-grained access control mappings against the IAM role actually presented. On the managed service the failure is usually a role that was mapped to an IAM ARN which changed, or a request signed by a different role than the backend role mapping expects. | 1–2 hours |
| Writes rejected once the domain nears its storage limit | Per-node EBS usage against the instance type's storage ceiling, plus shard skew across nodes. Managed domains cap volume size by instance family, so an oversized shard on one hot node can hit the wall while the cluster average looks fine. | 2–4 hours |
| Migrated from Elasticsearch and Dashboards features are missing | Which Kibana plugins the old deployment depended on. OpenSearch Dashboards reimplemented alerting, anomaly detection, and reporting rather than inheriting them, so saved objects usually import cleanly while plugin-backed features need rebuilding. | Same day |
Resolution times reflect typical OpenSearch engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
Everything in your OpenSearch support contract
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
- 02
Root Cause Analysis
Every P1 closes with a written RCA: what failed, why, the fix applied, and the shard, mapping, or policy change that prevents a repeat. Delivered as standard, not on request.
- 03
Query & Indexing Performance
Shard sizing, refresh interval and translog durability, mapping design, and query rewrites tuned against your actual traffic mix. We will tell you when the answer is an index template rather than a bigger instance type.
- 04
Elasticsearch to OpenSearch Migration
Snapshot-based migration, client library assessment, the compatibility.override_main_response_version bridge, ILM to ISM policy translation, and rebuilding the Kibana features that OpenSearch Dashboards implements differently.
- 05
Amazon OpenSearch Service Operations
Managed domain sizing, blue/green deploy planning, fine-grained access control and IAM role mapping, UltraWarm and cold tiering, and the storage ceilings that come with each instance family.
- 06
Security, CVE & Version Advisory
Alerts for CVEs affecting your exact OpenSearch version, plus tested upgrade paths across major versions and the security plugin configuration that comes with them.
Why AceMQ
What you get that you don't get elsewhere
Named Engineers, Zero Cold Start
The same senior engineers stay on your account. They know your index templates, your ISM policies, and your ingest pattern — so a P1 call opens with diagnosis instead of you re-explaining the environment.
No Tier-1 Triage Layer
You reach a senior OpenSearch engineer directly by phone, email, or Slack. Nobody collects details to pass along, and no escalation approval stands between you and the person who can fix it.
We Cover What AWS Support Won't
AWS will confirm the domain is healthy and the hardware is fine. They will not debug your mapping, rewrite the aggregation that trips your circuit breaker, or redesign your shard strategy. That gap is exactly where we work.
Both Sides of the Fork
We support OpenSearch and Elasticsearch in production, so migration advice comes from operating both rather than from a preference. Sometimes the honest answer is that the fork you are on is fine and the problem is elsewhere.
Genuine Follow-the-Sun Coverage
Engineers across 26+ countries and every time zone. Your 3am cluster red is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to come online.
Proactive, Not Just Reactive
Quarterly cluster health reviews plus shared intelligence across our support base. When a version-specific bug surfaces on one customer's cluster, every affected customer hears about it first.
We support OpenSearch wherever it's deployed
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
- Amazon OpenSearch Service (managed)
- Amazon OpenSearch Serverless
- Self-managed on AWS (EC2, EKS)
- Microsoft Azure (AKS)
- Google Cloud (GKE)
- Kubernetes & OpenShift
- VMware vSphere & Tanzu
- Bare metal & on-premise
- Air-gapped / no outbound access
- OpenSearch 1.x, 2.x and 3.x
- OpenSearch Dashboards
- Cross-cluster search & replication
Version coverage
OpenSearch versions and who covers them
OpenSearch is a Linux Foundation project, not a vendor product, so there is no vendor support contract to hold. The project maintains the current major and the previous one, and keeps a major in maintenance for at least a year after the next major arrives. AceMQ is independent of the project and of AWS, and works alongside your AWS support case on Amazon OpenSearch Service.
| OpenSearch version | Project status | Maintenance window | AceMQ cover |
|---|---|---|---|
| 3.x (3.9.0 released 29 Sep 2026) | Current | Current major, no end date | 24/7 support |
| 2.x (2.19 line) | Maintenance | Until the GA release of 4.0 | 24/7 support and upgrade planning to 3.x |
| 1.x (last release 1.3.20) | End of life | Ended 6 May 2025 | 24/7 support and upgrade planning to 2.x |
Source: the OpenSearch release schedule and maintenance policy (opensearch.org/releases), checked 20 October 2026. By default a version stays in maintenance until the next major enters maintenance or one year passes, whichever is longer. AceMQ response times: 15 minutes for emergencies, 1 hour for critical issues, 4 hours for high-priority issues and the next business day for standard questions.
Escalation Path
Your first hour of an OpenSearch outage
Every tier reaches a senior OpenSearch engineer. There is no tier-1 triage layer to get through.
- 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
- 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
- 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
- Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
T+Elapsed15:00
15-minute P1 response, 24/7.
A response time, not a resolution time.
- T+00:00Paged
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
- T+15:00Live
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
- T+30:00If needed
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
- AfterEvery P1
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
What does AceMQ OpenSearch support cost?
AceMQ OpenSearch support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, cloud-managed or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
OpenSearch problems we've already solved
OpenSearch support and remediation work from AceMQ. Each card links to the full write-up: the cluster or domain, what AceMQ diagnosed or changed, and the result.
OpenSearch Snapshot Restore Failure Remediation
Insurance Services Provider
Emergency recovery of an OpenSearch domain where snapshot restores were failing partway through and leaving indices in a red state.
OpenSearch
Amazon S3OpenSearch Dashboards
LinuxOpenSearch Cluster Support for Regulated Workloads
Public Sector Agency
24/7 enterprise support for OpenSearch clusters carrying regulated search and audit workloads, including security plugin and upgrade coverage.
OpenSearchOpenSearch DashboardsLinux
KubernetesElasticsearch to OpenSearch Migration Assessment
Digital Media Platform
Assessment of the technical and licensing implications of moving a large Elasticsearch estate to OpenSearch, including client and plugin compatibility.
OpenSearch
ElasticsearchAmazon S3
TerraformOpenSearch Multi-Tenant Search Architecture Design
B2B SaaS Platform Provider
Consulting engagement to design tenant isolation, index strategy, and query governance for OpenSearch serving thousands of customer tenants.
OpenSearchKubernetesOpenSearch DashboardsTerraform
Support options
Four tiers of OpenSearch support.
AceMQ offers OpenSearch support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for clusters and domains your team runs, proactive monitoring that catches shard, ISM and storage problems first, managed OpenSearch on your own infrastructure, and fully managed OpenSearch on AceMQ infrastructure. OpenSearch 1.x, 2.x and 3.x are covered, self-managed or on Amazon OpenSearch Service.
- Tier 1
OpenSearch 24/7 Support & Incident Management
You run it, we back you up
- A live bridge in 15 minutes, 24/7, for red clusters and stalled domain updates
- Diagnosis from allocation explain, ISM explain, CloudWatch and slow logs
- A written timeline and root cause after every P1
Best for: Teams that run OpenSearch themselves, on AWS or elsewhere, and need senior cover beyond what the platform provider answers.
- Tier 2
OpenSearch 24/7 Support with Proactive Monitoring
You run it, we watch it with you
- Scheduled reviews of shard count, storage headroom, JVM pressure and node roles
- ISM rollover, index template and Security plugin role checks
- Snapshot restore tests, including manual snapshots to another domain
Best for: Teams that want the blue/green stall or the lockout found in a review, not on a Friday evening.
- Tier 3
Managed OpenSearch on Your Infrastructure
We run it in your cloud or data centre
- 24/7 monitoring of cluster health, JVM pressure, storage and shard allocation
- Planned domain updates and rolling upgrades, rehearsed on a restored snapshot
- Security plugin, role mapping and tenant maintenance
Best for: Regulated estates that must keep search and audit data inside their own cloud account or network.
- Tier 4
Fully Managed OpenSearch on AceMQ Infrastructure
We host it and run it, as a service
- Cluster and Dashboards run as a service, with tenants kept separate
- Snapshots and restore tests run for you
- Upgrades, patching and index lifecycle owned by AceMQ
Best for: Teams that want OpenSearch search or log analytics without operating the cluster, and do not need it in their own account.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs OpenSearch day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for OpenSearch
Everything else AceMQ does for OpenSearch.
Support is one part of what AceMQ does for OpenSearch. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
- ConsultingOpenSearch consulting and services
- LifecycleEnd-of-life software support
- Enterprise supportOpen source support across your whole stack
- GuideOpenSearch guide
Support for the rest of your stack
Messaging & Streaming
- RabbitMQ supportMessaging & Streaming
- Apache Kafka supportMessaging & Streaming
- IBM MQ supportMessaging & Streaming
- ActiveMQ supportMessaging & Streaming
- Azure Service Bus supportMessaging & Streaming
- Amazon SQS supportMessaging & Streaming
- Google Cloud Pub/Sub supportMessaging & Streaming
- Redpanda supportMessaging & Streaming
- Apache Pulsar supportMessaging & Streaming
- Message Queuing supportMessaging & Streaming
Databases & Caching
Search & Analytics
Lakehouse & Compute
Observability & Monitoring
Data Integration
Cloud & Containers
API Management
See support for all 51 technologiesShow fewer
Related services
What does AceMQ OpenSearch support include?
Support covers 24/7 emergency incident response with a 15-minute SLA, written root cause analysis on every P1, query and indexing performance work, cluster and domain architecture review, migration support, and CVE and upgrade advisory. Every ticket goes to a named senior engineer assigned to your account. There is no tier-1 triage layer and no per-incident charge, so calling us during an outage is never a budget decision.
We run Amazon OpenSearch Service and already pay for AWS support. Why add this?
AWS support owns the infrastructure: the domain is healthy, the nodes are up, the service is meeting its own availability commitments. They will not debug why your aggregation trips the parent circuit breaker, why your shard strategy leaves one node hot, or why an ISM policy stopped rolling over. Most OpenSearch incidents live in that layer. We work there, and we work alongside your AWS support rather than replacing it.
How fast do you respond to an OpenSearch production outage?
P1 emergencies — cluster red, ingest stopped, search failing for users — get a 15-minute first response with a senior engineer on a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times rather than best-effort targets, and they hold at 3am on a Sunday.
Can you help us migrate from Elasticsearch 7.10 to OpenSearch?
Yes, and this is one of the more common engagements we take. The index data migrates cleanly via snapshot restore, but the work around it is where projects stall: client libraries that refuse to talk to a non-Elasticsearch version response, ILM policies that need translating into ISM, and Kibana features that OpenSearch Dashboards implements differently rather than identically. We plan the cutover with a parallel-run window so you can validate before switching traffic.
Why do our Elasticsearch clients fail against OpenSearch?
Older Elasticsearch clients check the version string returned by the cluster root endpoint and refuse to proceed against anything they do not recognise. OpenSearch reports its own version there, which those clients reject. The compatibility.override_main_response_version setting makes the cluster report 7.10.2 instead, which unblocks you immediately. Treat it as a bridge rather than a destination — we help plan the client library migration behind it.
Do you support OpenSearch Dashboards as well as the cluster?
Yes. Dashboards problems are frequently cluster problems wearing a different hat: a visualisation that times out is usually an unbounded aggregation, and a slow dashboard is often twenty panels each firing their own expensive query. We cover the Dashboards layer, the saved objects, the alerting plugin, and the query cost underneath all of it.
Who maintains OpenSearch, and how is it licensed?
OpenSearch is an open source search and analytics suite that began in 2021 as a fork of Elasticsearch and Kibana 7.10, after Elastic moved those products from the Apache License to the Elastic License and SSPL. OpenSearch and OpenSearch Dashboards remain under the Apache License 2.0. Amazon Web Services created the project and in 2024 transferred it to the OpenSearch Software Foundation under the Linux Foundation, which now governs the OpenSearch project with contributors from several companies. Amazon OpenSearch Service is the AWS managed offering, the successor to Amazon Elasticsearch Service, and still hosts some versions of Elasticsearch alongside versions of OpenSearch. Elastic does not support OpenSearch, and neither the project nor the foundation sells support, which is where AceMQ fits for self-managed clusters and for workloads on the managed service.
Can you upgrade OpenSearch in place without downtime, and which versions are supported?
Rolling upgrades work for self-managed clusters within a major version and from the last minor of one major to the next, so an OpenSearch 1.3 cluster moves to 2.x and then 3.x without a full outage, with a reindex for any index originally created on Elasticsearch 6.x. The OpenSearch project maintains 3.x as current and 2.x until OpenSearch 4.0 ships; 1.x reached end of life in May 2025. On Amazon OpenSearch Service an upgrade is a blue/green deployment triggered from the console, and its duration depends on shard count and free storage, which is why we rehearse it on a restored snapshot first. Migrating data from an existing Elasticsearch or OpenSearch cluster to a new domain uses snapshot and restore or remote reindex, and the client libraries must move to the OpenSearch clients, because Elasticsearch clients from 7.14 onwards refuse to connect.
Can we work with AceMQ on OpenSearch without a long contract?
Yes. AceMQ works on OpenSearch in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
How much does AceMQ OpenSearch support or consulting cost?
Every AceMQ proposal is tailored to your requirements: your OpenSearch environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how OpenSearch is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Your OpenSearch Cluster Is Only as Good as Who Answers at 3am
Reactive cover, proactive reviews, or AceMQ running OpenSearch for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
A senior OpenSearch engineer, not a sales queueQuote requests answered within 1 hourAd hoc engagements or an annual partnership
Production incident right now?Email an OpenSearch Architect
Get in Touch
Talk to an OpenSearch Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.