What does AceMQ Apache Cassandra support include?

Cassandra support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, data model review, compaction and repair strategy, JVM and GC tuning, CVE and patch advisory, quarterly health checks, and upgrade or multi-DC expansion support. Every ticket goes to a named senior engineer assigned to your account. There is no tier-1 triage layer and no per-incident charge.

Our reads started timing out on a table we delete from frequently. What is happening?

That is the tombstone problem, and it is the single most common Cassandra incident we are called for. Cassandra does not remove data on delete; it writes a tombstone marker that has to be scanned on every subsequent read of that partition until it ages past gc_grace_seconds and a compaction removes it. Frequent deletes or short TTLs on a table therefore make reads progressively more expensive, and a query that scans past tombstone_failure_threshold is aborted outright. We fix it in layers: immediate relief through targeted compaction, then a repair schedule that actually completes, then the data model change that stops generating the tombstones — usually a switch to time-bucketed partitions with TWCS instead of in-place deletes.

How fast do you respond to a Cassandra production outage?

P1 emergencies — multiple nodes down, reads or writes failing cluster-wide, a ring that won't converge — get a 15-minute first response with a senior engineer joining 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 covering nights, weekends, and holidays.

Do you support DataStax Enterprise and Amazon Keyspaces as well as open source Cassandra?

Yes. We support Apache Cassandra 3.11 through 5.0, DataStax Enterprise, Azure Managed Instance for Apache Cassandra, and Amazon Keyspaces. The managed and commercial variants remove some operational surface — Keyspaces in particular hides compaction and repair entirely — but they do not remove partition sizing, consistency level design, or the cost model consequences of a wide partition. We are also frequently asked to compare them honestly for a specific workload, including where the managed option genuinely wins.

How often does repair actually need to run, and why does it keep failing?

Every table needs a full repair to complete within gc_grace_seconds, which defaults to ten days. If it does not, tombstones can be purged before every replica has seen them and deleted data comes back. Repairs fail or overrun for a handful of recurring reasons: very wide partitions that blow past stream timeouts, insufficient compaction throughput, running full repairs where incremental or subrange would fit the window, and overlapping repair sessions competing for the same ranges. We usually move customers onto a subrange schedule driven by a scheduler such as Reaper, sized so the whole ring completes with margin rather than finishing on the last day.

Can you help us upgrade from Cassandra 3.11 to 4.x or 5.0?

Yes, and this is a rolling upgrade that has to be sequenced carefully rather than a package update. SSTable format changes mean nodes on different major versions cannot stream to each other, so no bootstrap, decommission, or repair can run until the whole ring is upgraded — which makes the window between the first and last node the risky part. We rehearse on a cloned cluster, verify driver compatibility, upgrade SSTables node by node, and keep a tested rollback point. We also check for deprecated configuration and CQL behaviour changes that surface as application errors rather than server errors.

How is AceMQ Cassandra support priced?

Support is an annual contract priced on cluster size, required SLA tier, and coverage hours — not per incident and not per ticket. That structure exists so nobody hesitates to page us during an outage. Quotes are returned within 24 hours and scoped against your actual topology, including multi-DC layouts, rather than a node count on a form.

Cassandra Support

24/7 Apache Cassandra Support with a 15-Minute Emergency SLA

AceMQ supports Apache Cassandra in production — tombstone accumulation that turns a point read into a timeout, partitions that grew past a gigabyte, repairs that never finish inside gc_grace_seconds, and compaction strategies chosen for the wrong workload. Multi-DC, DSE, or Kubernetes. Every ticket reaches a named senior engineer.

Senior Apache Cassandra 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 Apache Cassandra by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a Apache Cassandra 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 Apache Cassandra 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

Apache Cassandra problems we fix every week

These are real symptoms from real Apache Cassandra production environments — and the first thing our engineers check when one comes in.

Symptom you're seeingWhat we check firstTypical resolution

Read timeouts on a table with heavy deletes or short TTLs

What we check firstTombstone counts per read in the system log against tombstone_warn_threshold, and how long since compaction last purged them. Every delete and every expired TTL cell is a tombstone that must be scanned on each read until it ages past gc_grace_seconds and compacts away.

Typical resolution1–3 hours

Nodes marked down and back up repeatedly with no network fault

What we check firstGC logs for stop-the-world pause duration first. A multi-second pause makes gossip miss heartbeats and the cluster convicts a node that is actually alive. The underlying cause is usually a wide partition or a large read being pulled into heap, not the JVM settings themselves.

Typical resolution2–4 hours

One partition is enormous — nodetool tablehistograms shows gigabytes

What we check firstThe partition key design against real cardinality. A key with too few distinct values concentrates unbounded writes into one partition, which then causes GC pressure, slow repairs, and streaming failures. The fix is a bucketing component in the key and a backfill, not a tuning parameter.

Typical resolution2–4 hours

Deleted rows reappearing in query results

What we check firstRepair completion history against gc_grace_seconds per table. If a replica misses a delete and the tombstone is purged before repair propagates it, the stale live value wins on the next read. We verify the repair schedule actually completes inside the window rather than merely being scheduled.

Typical resolution1–3 hours

Reads degrading as SSTable count climbs steadily

What we check firstCompaction strategy against the actual workload, plus pending compaction tasks and the throughput throttle. Size-tiered on a time-series table that should be TWCS, or leveled on a write-heavy table, both produce this — compaction never catches up and each read touches more SSTables.

Typical resolution2–4 hours

UnavailableException while every node shows as up

What we check firstConsistency level against replication factor per keyspace per datacenter. LOCAL_QUORUM with a datacenter name in NetworkTopologyStrategy that doesn't match the snitch's actual DC name means replicas are placed somewhere the coordinator won't count, so quorum can never be met locally.

Typical resolutionUnder 1 hour

Adding or decommissioning a node fails part way through streaming

What we check firstStreaming throughput and timeout settings, and nodetool describecluster for schema disagreement. Multiple schema versions across the ring will break bootstrap outright, and a wide partition can exceed the stream timeout before a single file finishes transferring.

Typical resolutionSame day

Cluster stays slow for hours after a node comes back from an outage

What we check firstHint replay volume and read repair activity. The recovered node is being written to by every coordinator at once while also serving reads it can't satisfy from local data — we throttle hinted handoff and check whether hints exceeded max_hint_window and a repair is required instead.

Typical resolution1–2 hours

Resolution times reflect typical Apache Cassandra 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

Apache Cassandra problems we've already solved

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

All use cases

Remediation

Cassandra Tombstone Accumulation and Read Timeout Remediation

Connected Vehicle Telematics Provider

Resolving read timeouts caused by tombstone accumulation on queue-like partitions where deletes outpaced compaction and gc_grace_seconds.

Apache CassandraKubernetesPrometheus

Read case study

Support

Cassandra Repair and Compaction Support

Global Payments Processor

Ongoing support for anti-entropy repair that never completed within gc_grace_seconds, leaving the cluster exposed to deleted data resurrecting.

Apache CassandraReaperPrometheus

Read case study

Assessment

Cassandra Cluster Health and Capacity Assessment

Public Sector Agency

Assessment covering topology, replication and consistency configuration, JVM and garbage collection behavior, compaction health, and growth headroom.

Apache CassandraLinuxPrometheus

Read case study

What's Included

Everything in your Apache Cassandra support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency Incident Response

Nodes down, reads timing out, a ring that won't converge, or a bootstrap stuck mid-stream. A senior engineer joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.

Root Cause Analysis

Every P1 closes with a written RCA: what failed, why, the fix applied, and the data model, compaction, or repair change that prevents recurrence. Delivered as standard, not on request.

Data Model Review

Partition key and clustering column design against your real access patterns, partition size distribution, and the delete and TTL patterns that quietly manufacture tombstones faster than compaction can remove them.

Compaction & Repair Strategy

Compaction strategy matched to workload — TWCS for time series, LCS for read-heavy, STCS where it genuinely fits — plus a repair schedule that completes inside gc_grace_seconds rather than merely existing in cron.

JVM & GC Tuning

Heap sizing, G1 versus ZGC selection for your pause budget, and off-heap memory accounting. We tune GC after fixing what is filling the heap, because the reverse order just moves the outage later.

Upgrades, Multi-DC & Migrations

Rolling upgrades across 3.11, 4.x, and 5.0, adding or retiring a datacenter without downtime, and migrations to or from DataStax Enterprise, Amazon Keyspaces, and ScyllaDB.

Anywhere You Run It

We support Apache Cassandra wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

Apache Cassandra 3.11, 4.x, 5.0DataStax Enterprise (DSE)Amazon KeyspacesAzure Managed Instance for Apache CassandraK8ssandra & Cass Operator on KubernetesOpenShiftMulti-DC across AWS, Azure, and GCPAWS (EC2, EKS) with instance-store or EBSScyllaDB migrationsBare metal & on-premiseAir-gapped / no outbound accessHybrid cloud

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 keyspace layout, your replication factors, and your compaction choices — so a P1 call opens with a hypothesis rather than a tour of your ring.

No Tier-1 Triage Layer

You reach a senior Cassandra engineer directly by phone, email, or Slack. No help desk collecting details to relay, and no escalation approval between you and someone who can read a GC log and a tablehistogram.

We Treat Data Model Issues as Data Model Issues

Most Cassandra production pain traces back to partition key design and delete patterns. We will say when the answer is a model change and a backfill rather than more nodes — even though more nodes would be the easier recommendation to make.

Multi-DC Without the Guesswork

Cross-datacenter replication, LOCAL_QUORUM semantics, snitch and topology configuration, and adding or retiring a DC live. This is where consistency mistakes hide until the day one region becomes unreachable.

Genuine Follow-the-Sun Coverage

Engineers across 26+ countries and every time zone. Your 3am node flap is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.

Full-Stack, Not Just the Ring

We diagnose across the driver's load balancing and retry policy, the JVM, storage latency, network policy, and Kubernetes. Cassandra symptoms frequently originate in the client or the disk rather than in Cassandra.

FAQ

Apache Cassandra support questions

Cassandra Fails Slowly, Then All at Once

Tombstones, wide partitions, and missed repairs build for months before they page anyone. Whether you need emergency response tonight or a contract that catches them early, AceMQ staffs every engagement with a named senior Cassandra engineer. 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.