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.

How is AceMQ OpenSearch support priced?

Support is an annual contract priced on cluster or domain count, data volume, required SLA tier, and coverage hours — never per incident or per ticket. Contact us with your environment details and we return a quote within 24 hours.

OpenSearch Support

24/7 OpenSearch Support with a 15-Minute Emergency SLA

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.

Senior OpenSearch engineers on call right now — 24/7/365

15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Available Now

Book a free Consultation.

Prefer to chat first?

Prefer to E-mail?

info@acemq.com

Trusted for mission-critical OpenSearch by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a OpenSearch outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior OpenSearch engineer. There is no tier-1 triage layer to get through.

P1 — Emergency

15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical

1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High

4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard

Next day

Questions, guidance, best practices, non-urgent improvements

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 seeingWhat we check firstTypical resolution

Cluster red or yellow with shards refusing to allocate

What we check firstThe 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.

Typical resolutionUnder 1 hour

Elasticsearch clients throw a version error against OpenSearch

What we check firstWhether 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.

Typical resolutionUnder 1 hour

Heap above 85% and circuit breakers tripping under dashboard load

What we check firstThe 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.

Typical resolution1–2 hours

ISM policy stopped rolling over — one index growing without bound

What we check firstThe 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.

Typical resolutionUnder 2 hours

Amazon OpenSearch Service stuck in a blue/green deployment

What we check firstWhich 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.

Typical resolutionSame day

403 security_exception on requests that used to work

What we check firstFine-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.

Typical resolution1–2 hours

Writes rejected once the domain nears its storage limit

What we check firstPer-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.

Typical resolution2–4 hours

Migrated from Elasticsearch and Dashboards features are missing

What we check firstWhich 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.

Typical resolutionSame day

Resolution times reflect typical OpenSearch engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking

Support In Practice

OpenSearch problems we've already solved

Representative engagements showing how these incidents get diagnosed and closed under an AceMQ support contract.

All use cases

Remediation

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.

OpenSearchAmazon S3OpenSearch Dashboards

Read case study

Support

OpenSearch 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

Read case study

Assessment

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

OpenSearchElasticsearchAmazon S3

Read case study

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.

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.

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.

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.

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.

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.

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.

Anywhere You Run It

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 ServerlessSelf-managed on AWS (EC2, EKS)Microsoft Azure (AKS)Google Cloud (GKE)Kubernetes & OpenShiftVMware vSphere & TanzuBare metal & on-premiseAir-gapped / no outbound accessOpenSearch 1.x, 2.x and 3.xOpenSearch DashboardsCross-cluster search & replication

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.

FAQ

OpenSearch support questions

Your OpenSearch Cluster Is Only as Good as Who Answers at 3am

Whether you need emergency response tonight or a support contract that prevents the next outage, AceMQ staffs every engagement with a named senior OpenSearch engineer. Support quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.