Free audit

View Audit Scope
OpenSearch SupportProduction support, shard recovery & maintenance

OpenSearch Support Services & Incident Response

JusDB provides OpenSearch support services, cluster maintenance, and incident response for production search and log analytics clusters on Amazon OpenSearch Service, Kubernetes, and self-managed servers. Search engineers monitor cluster health, recover RED and YELLOW unassigned shards, resolve JVM heap pressure and 429 circuit breakers, verify S3 snapshots, and keep OpenSearch 2.x running under your service agreement.

Book a 30-min scoping call (opens Google Calendar in a new tab)See what is included

The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance.

  • NDA before access
  • Read-only by default
  • Written scope before work starts

OpenSearch support tracks

Select your operational state

OpenSearch 2.x production support on AWS, Kubernetes & VMs

Active support

Full operational coverage for OpenSearch 2.11 through 2.17+ including Segment Replication, ISM rollover health, k-NN off-heap memory, and S3 snapshot verification.

See what is included

Lifecycle dates checked against the OpenSearch release schedule.

Platforms supported
Amazon OpenSearch Service, OpenSearch on Kubernetes, AWS EC2, Google Cloud, Azure, and bare-metal servers
Initial-response targets
15 minutes for a critical (P1) incident under a 24x7 support agreement; 2 to 4 hours in business hours. See details
Coverage hours
Business hours (03:30–12:30 UTC) by default; 24x7 on-call available under a 24x7 support agreement

Selected clients

  • Innoviti
  • Blitz
  • Freecharge
  • Nango
  • Recochain
  • Screen Facts
  • Nexora
  • WeCredit

When teams call us

Common OpenSearch incidents we resolve

Common OpenSearch incidents we resolve include RED unassigned primary shards, 95% flood-stage read-only locks, JVM Old Gen GC storms, thread pool rejections, stalled ISM rollovers, and stuck AWS blue/green updates.

Common OpenSearch production symptoms, what is usually happening, and where JusDB engineers start
SymptomWhat is usually happeningWhere we start
CLUSTER_STATUS_REDCluster status drops to RED and search requests return partial or 503 errorsOne or more primary shards are UNASSIGNED after a data node crash, disk full event, or corrupt Lucene translog.Run GET _cluster/allocation/explain on the unassigned primary, verify node storage health, retry allocation via _cluster/reroute?retry_failed=true, or restore from S3 snapshot.
DISK_FLOOD_STAGE_READONLYIndices lock into read_only_allow_delete and ingestion stopsA data node crossed the 95% cluster.routing.allocation.disk.watermark.flood_stage threshold due to stalled ISM deletion or uneven shard placement.Relieve disk space or relocate oversized shards, fix the blocked ISM policy, and reset index.blocks.read_only_allow_delete: null.
JVM_OLD_GEN_GC_STORMData nodes drop out of cluster with master_not_discovered_exceptionStop-the-world JVM garbage collection pauses exceed cluster.fault_detection.follower_check.timeout because of oversharding or heavy fielddata aggregations.Inspect _nodes/hot_threads and GC logs, cancel runaway tasks via _tasks/_cancel, and reduce shard density and aggregation bucket limits.
SEARCH_THREADPOOL_REJECTQueries fail with EsRejectedExecutionException on search or write queuesSlow unindexed wildcard/regex queries or unbatched _bulk requests saturate fixed thread pool queues (search queue 1000 / write queue 200).Check _cat/thread_pool/search,write?v, isolate slow queries in index.search.slowlog, and enable Segment Replication to free CPU cores.
ISM_ROLLOVER_STALLEDA single write index grows past 800 GB instead of rolling overMisconfigured is_write_index alias flags or template collisions prevent the ISM rollover action from creating the next generation index.Run GET _plugins/_ism/explain/<index>, repair the write alias pointer atomically via _aliases, and retry the failed ISM step.
BLUE_GREEN_UPGRADE_STUCKAmazon OpenSearch Service domain update hangs at 90% for hoursUnassigned replica shards, high JVM pressure, or incompatible index settings block the managed blue/green shard migration check.Audit domain upgrade eligibility logs, resolve YELLOW replica allocation blocks, and throttle ingestion during the blue/green switch.

Response targets and escalation

How fast does JusDB respond to an OpenSearch incident?

Initial-response targets are 2 to 4 hours during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30). Where your service agreement includes 24x7 on-call, the initial-response target for P1 incidents is 15 minutes. Targets are not resolution guarantees. Standard business hours run 03:30–12:30 UTC.

Published initial-response targets by severity

  • 2 to 4 hours

    Business hours

    During covered business hours

  • 15 minutes

    24x7 on-call

    P1 incidents

SeverityInitial responseDefinitionChannel & coverage
P1 · Critical15 minutesProduction database down, primary unreachable, data corruption risk, or active failover event.24x7 on-call (under your service agreement) · Direct PagerDuty, Opsgenie, or phone page plus incident bridge
P2 · High30 minutesSevere latency spike, replication lag climbing rapidly, connection exhaustion, or degraded HA node.24x7 on-call (under your service agreement) · On-call alert plus shared Slack or Teams channel
P3 · Medium60 minutesNon-critical slow query regression, staging issue, backup warning, or replication check alert.24x7 on-call (under your service agreement) · Shared Slack or Teams channel or support ticket
P4 · Low90 minutesConfiguration question, index advisory, planned schema review, or general operational request.24x7 on-call (under your service agreement) · Shared Slack or Teams channel or support ticket

Our engineering team is in India; business-hours coverage is Mon–Fri 09:00–18:00 IST (UTC+5:30), and 24x7 on-call is available under your service agreement.

Initial-response targets, not resolution guarantees. The target for your engagement is set in your service agreement.

What happens when a P1 OpenSearch incident pages

  1. Page

    An alert or your team pages the on-call OpenSearch engineer

    Routed directly under your service agreement with no tier-1 queue.

  2. Triage

    Read-only diagnosis via _cluster/allocation/explain and _nodes/stats

    Isolate unassigned shards, flood-stage locks, or JVM GC stalls.

  3. Mitigate

    Restore GREEN status and search availability with your approval

    Reroute failed shards, cancel runaway tasks, or clear read-only blocks.

  4. Review

    Written post-incident review after every P1

    Root cause, telemetry evidence, and the ISM or shard change that prevents recurrence.

Scope of support

What does an OpenSearch support agreement cover?

A support agreement covers incident response, cluster and JVM health monitoring, shard and ISM lifecycle care, slow-query diagnostics, S3 snapshot verification, and version upgrade execution.

  • Incident response & on-call escalation

    Direct escalation to senior OpenSearch engineers when RED cluster states, JVM circuit breaker trips, or ingestion stalls hit production.

    • Within 15 minutes initial response for P1 incidents under a 24x7 support agreement
    • Within 1 hour initial response for P1 incidents in covered business hours

    PagerDuty · Slack Bridge · _cluster/allocation/explain · _tasks

  • Proactive cluster & JVM health monitoring

    Continuous tracking of shard counts, JVM heap old-gen occupancy, GC pause duration, thread pool rejections, and disk watermarks.

    • Early warning alerts before 85% low and 90% high disk watermarks trip
    • ClusterManager pending task and ISM policy failure monitoring

    Prometheus Exporter · CloudWatch · Grafana · _nodes/stats

  • Shard balancing & ISM lifecycle care

    We maintain Index State Management (ISM) policies, rollover aliases, and shard allocation awareness across availability zones.

    • Ongoing enforcement of 20-50 GB shard sizing targets
    • Hot-to-Warm-to-Cold/UltraWarm transition monitoring and force-merge tuning

    ISM Policies · _aliases · Shard Allocation Awareness

    Explore OpenSearch consulting

  • Slow-query & bulk indexing optimization

    Weekly reviews of search and indexing slow logs to catch expensive wildcard queries, script scores, and mapping regressions.

    • Search slowlog forensics and composite aggregation tuning
    • Bulk queue sizing, refresh_interval tuning, and Segment Replication care

    search.slowlog · _nodes/hot_threads · Profile API

  • S3 snapshot verification & DR drills

    We manage automated snapshot repositories on S3, GCS, or Azure Blob Storage and test index restores so recovery is predictable.

    • Monitoring of Snapshot Management (SM) schedules and repository permissions
    • Scheduled test restores and Cross-Cluster Replication (CCR) lag checks

    _snapshot · Snapshot Management · S3 / GCS · CCR

  • Rolling upgrades & security maintenance

    Safe execution of minor patches and major version upgrades across self-managed nodes, Kubernetes Operators, and AWS domains.

    • Pre-upgrade deprecation checks, shard allocation disable/enable orchestration
    • TLS certificate rotation, FGAC role audits, and security plugin patching

    Rolling Restart · OpenSearch Operator · Security Plugin

    Explore OpenSearch on Kubernetes

Shard recovery and written evidence

How OpenSearch handles node failures and RED shards

Without delayed allocation timeouts and zone awareness, a brief node reboot triggers a multi-terabyte shard rebalance storm. See how we manage GREEN, YELLOW, and RED states.

Three OpenSearch cluster health and shard allocation states

Choose a state to see how primary/replica shards and client traffic behave.

Search and ingest routing

Search & Bulk Ingest -> Coordinating / Ingest Nodes -> Balanced [P0]/[R0] across AZs

Normal operations

  • ClusterManager Quorum (3 AZs)

    cm-az1, cm-az2, cm-az3 (Dedicated)

    0 pending tasks; fast cluster state

  • Data Node AZ-a (Primary)

    data-az1-01 (Primary Shard [P0])

    Indexes docs & ships segments to replica

  • Data Node AZ-b (Replica)

    data-az2-01 (Replica Shard [R0])

    Receives Segment Replication in < 1s

cluster.routing.allocation.awareness.attributes: zone ensures primary and replica shards never sit in the same availability zone. JVM heap stays between 40% and 65%.

Example written finding from a RED unassigned shard & disk flood-stage incidentSample deliverable

Finding

95% flood-stage watermark on data-04 locks 62 write indices read-only

A single unrolled 740 GB index pinned to data-04 pushed disk usage to 95.4%, tripping disk.watermark.flood_stage and locking all 62 indices on that node into read_only_allow_delete. Relocating 2 warm shards, fixing the rollover alias, and clearing the block restored ingestion in 9 minutes.

Time to restore writes9 minutes
data-04 disk utilization95.4% → 68%

1. Read-only check explaining why shard allocation stopped

GET _cluster/allocation/explain
{
  "index": "logs-payments-000042",
  "shard": 2,
  "primary": true
}

2. Clear read_only_allow_delete block and retry failed shards

PUT _all/_settings
{
  "index.blocks.read_only_allow_delete": null
}
POST _cluster/reroute?retry_failed=true

Your team and ours

What a managed OpenSearch service still leaves to your team

Managed cloud databases automate much of the infrastructure layer, but your team still owns query performance, capacity, cost, and incident decisions.

Who handles each part of running OpenSearch on a managed cloud service versus your own servers
AreaManaged cloud (Amazon OpenSearch Service)Your own servers or Kubernetes
24x7 cluster monitoring, RED/YELLOW recovery, and on-call triageAWS monitors underlying hardware, but unassigned shards, 429 circuit breakers, and read-only flood-stage locks still page your team.JusDB monitors cluster health and responds to incidents under your service agreement.
JVM heap pressure, GC pause forensics, and slow-query cancellationCloud support tickets do not cancel runaway user queries or redesign your high-cardinality aggregations.JusDB inspects _tasks and _nodes/hot_threads, cancels offending tasks, and optimizes queries.
Index State Management (ISM) maintenance and shard consolidationStalled ISM policies on managed domains silently fill EBS volumes until flood-stage locks trigger.JusDB monitors ISM execution, repairs broken rollover aliases, and shrinks oversharded indices.
S3 snapshot verification and index-level restore drillsAutomated hourly snapshots run on AWS, but selective index restoration and cross-region DR remain your team's job.JusDB manages _snapshot repositories, monitors snapshot failures, and conducts restore drills.
Rolling node restarts and version upgradesBlue/green domain upgrades are triggered by your team and can stall if pre-flight checks fail.JusDB runs pre-upgrade deprecation audits and executes rolling restarts with allocation guards.

Your team keeps control

  • Set business priorities, application requirements, and release plans
  • Approve production changes, except routine actions you have pre-approved
  • Own your cloud accounts, access policies, and vendor relationships
  • Decide when maintenance can happen and how quickly service must recover
  • Move the work in-house or to another provider after your agreement's notice period, with your data returned or deleted and the transition help your agreement sets out (Terms, section 8)

JusDB handles the agreed OpenSearch work

  • Monitor database health, investigate alerts, and involve the right people
  • Review query performance, replication, capacity, and backup health
  • Carry out approved changes and update the operating instructions they affect
  • Report completed work, open risks, and recommended next steps

Where your OpenSearch runs

Compare options

How JusDB OpenSearch Support compares with vendor tickets and hiring

Compare an agreed JusDB support scope against cloud vendor ticketing alone or hiring a full-time search infrastructure team.

Evaluation VectorJusDB OpenSearch SREAWS OpenSearch ServiceIn-House Generalists
Shard Distribution & ISM AutomationHot/UltraWarm/Cold storage tiering, automated ISM rollover policies, 30-50GB shard sizing, automated unassigned shard recoveryManaged ISM policies available, but improper shard allocation still triggers cluster red/yellow alerts and throttlingOversharded clusters with thousands of small indices, cluster manager node starvation, and manual rollover failures
JVM Heap Sizing & Circuit BreakersFine-grained heap tuning (capped under 31GB for compressed OOPs), parent & fielddata breaker calibration, zero GC pausesFixed instance types with locked heap ratios; circuit breaker trips cause 429 Too Many Requests without query root-cause analysisHeaps misconfigured past 32GB or starving Lucene off-heap memory, leading to recurring STW pauses and node drops
AWS OpenSearch Service Optimization & FinOpsGraviton migration, GP3 IOPS/throughput rightsizing, UltraWarm/Cold tier optimization, with cloud spend measured against your baselineDefault provisioned EBS IOPS and high on-demand instance pricing with no proactive architectural rightsizing assistanceOver-provisioned hot nodes running year-round for historical log data that could safely reside in cold/S3 storage
Vector Search & k-NN Plugin ArchitectureHNSW/IVF index tuning, Faiss & NMSLIB engine calibration, memory-mapped vector cache sizing for sub-10ms RAG retrievalBasic k-NN plugin enabled, but vector index building on data nodes frequently triggers CPU spikes and query throttlingNaive vector deployments consuming entire JVM heap, triggering fatal OutOfMemory errors during concurrent queries
Incident Response & EscalationNamed OpenSearch engineers join your incident bridge. Initial-response targets: 2 to 4 hours in covered business hours; 15 minutes for P1 incidents with 24x7 on-call. Targets, not resolution guarantees.AWS Support ticket routing through generalist cloud support with multi-hour triage delays for cluster health recoveryDeveloper alert fatigue diagnosing cluster manager election deadlocks and shard allocation blocks at 3 AM
Low-Downtime ES to OpenSearch MigrationLive dual-write streaming, remote reindex, snapshot/restore validation, mapping translation, low-downtime cutoverSnapshot restore from ES 7.10 supported, but incompatible plugins and custom mapping changes require manual fixesHigh-risk cutovers with search downtime, data discrepancies, and application query syntax failures
This page

OpenSearch support

Your team builds search features; JusDB monitors cluster health, resolves RED/YELLOW incidents under your agreement, and maintains ISM policies.

See response targetsScoped project

OpenSearch consulting

A fixed-scope engagement for shard consolidation, ISM Hot-Warm-Cold design, k-NN vector search tuning, or an Elasticsearch migration.

Explore OpenSearch consultingCloud-native K8s

OpenSearch on Kubernetes

Deploy and operate OpenSearchCluster CRDs with the official OpenSearch Kubernetes Operator on EKS, GKE, and AKS.

Explore OpenSearch on Kubernetes

For procurement and security

NDA first, read-only by default, and written scope

We work alongside your engineering and infrastructure teams. Your team approves production changes and keeps every runbook and post-incident report.Raguraman, Engineering Manager · Allen D, Lead Database SRE
  • Mutual NDA
  • Written statement of work
  • Named engineers
  • Least-privilege access

  • NDA before access

    Signed before any diagnostic access. The scoping call needs no cluster credentials.

  • Written agreement

    Covered OpenSearch clusters, hours, response targets, and fees agreed in writing before onboarding.

  • Least-privilege accounts

    Named read-only accounts by default, through your bastion or VPN, with session logging.

  • Runbooks you keep

    Every recovery procedure, finding, and configuration note stays with your team. Meet the JusDB team.

JusDB's security practices are aligned with ISO 27001 and SOC 2 Type II, and JusDB is pursuing both certifications (see Terms, section 12). Read the stated status.

FAQ

Common OpenSearch support questions

Answers on response targets, RED cluster recovery, flood-stage read-only blocks, delayed shard allocation, and Amazon OpenSearch Service.

Still have a question?

Ask it on a scoping call. No production access needed.

Book a 30-min scoping call (opens Google Calendar in a new tab)

What does a JusDB OpenSearch support agreement cover?

A support agreement covers incident response for RED/YELLOW cluster states and circuit breaker errors, proactive JVM and disk watermark monitoring, Index State Management (ISM) policy maintenance, slow-query and bulk-indexing optimization, S3 snapshot verification, and version upgrade execution across Amazon OpenSearch Service, Kubernetes, and self-managed nodes.

How fast does JusDB respond to a P1 OpenSearch outage?

Initial-response targets are 2 to 4 hours during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30). Where your service agreement includes 24x7 on-call, the initial-response target for P1 incidents is 15 minutes. Targets are not resolution guarantees.

How do you recover an OpenSearch cluster when status turns RED?

A RED status means at least one primary shard is unassigned. We immediately run GET _cluster/allocation/explain for the affected index and shard to determine whether allocation failed due to a missing node, disk watermark limits, or max_retries exhaustion (5 failed attempts). Once the underlying node or disk issue is cleared, we issue POST _cluster/reroute?retry_failed=true or restore the specific index from your most recent S3 snapshot.

Why did all our OpenSearch indices suddenly become read-only?

When any data node's disk usage crosses cluster.routing.allocation.disk.watermark.flood_stage (95% by default), OpenSearch automatically sets index.blocks.read_only_allow_delete: true on every index sharing that node to prevent disk corruption. Even after freeing disk space, older releases or stuck states may require explicitly resetting read_only_allow_delete to null via the _settings API.

How do you prevent multi-terabyte shard rebalancing storms during a node restart?

Before planned maintenance on a self-managed or Kubernetes node, we temporarily set cluster.routing.allocation.enable to 'primaries', flush translogs with POST _flush/synced, restart the node, and re-enable allocation once the node rejoins. For unplanned reboots, we configure index.unassigned.node_left.delayed_timeout (e.g., 5m) so OpenSearch waits 5 minutes before copying shards across the network.

Can you support our domains on Amazon OpenSearch Service?

Yes. While AWS manages the underlying EC2 instances, your engineering team is still responsible for shard counts, JVM heap usage, 429 circuit breakers, ISM policies, UltraWarm transitions, and slow queries. We act as your dedicated OpenSearch SRE team on top of AWS.

Do you support OpenSearch Dashboards, Alerting, and Security plugins?

Yes. We configure and troubleshoot the OpenSearch Security plugin (TLS certificates, SAML/OIDC, Fine-Grained Access Control, DLS/FLS), Index State Management, Alerting monitors, Anomaly Detection, and k-NN vector search plugins.

How do we start an OpenSearch support engagement?

We begin with a 30-minute scoping call and mutual NDA, followed by a read-only baseline health audit of your cluster settings, shard distribution, JVM heap telemetry, and backup repositories. We then onboard your alerts into our rotation under a written statement of work.

OpenSearch playbooks and guides

Shard sizing, ISM lifecycle, and search operations guides

Practical guides from our engineering blog on shard consolidation, JVM heap tuning, and OpenSearch vs Elasticsearch.

Next step

Talk to an OpenSearch engineer about your clusters

Tell us which OpenSearch versions and platforms you run and what you need covered. The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.

Book a 30-min scoping call (opens Google Calendar in a new tab)Request a free audit

NDA before access · read-only by default · written scope first

Related OpenSearch Services

Explore more ways our OpenSearch experts can help with your database infrastructure.

OpenSearch ConsultingOpenSearch Kubernetes
View all OpenSearch services