What does AceMQ Valkey support include?

Our Tanzu Valkey support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, latency and memory tuning, cluster and failover operations, Redis-to-Valkey migration, version upgrades, and Broadcom licensing support. Every ticket is handled by a named senior engineer assigned to your account. There is no tier-1 triage layer and no per-incident charge.

Is Valkey experience really the same as Redis experience?

Operationally, yes — and that is the point. Valkey forked from Redis 7.2, so the failure modes, the INFO fields, the persistence mechanics, the cluster slot model, and the kernel interactions are the same ones engineers have been debugging for a decade. Divergence so far is mostly in newer features and threading work rather than in the surface that breaks at 3am. We track the differences that matter and tell you when one applies to your case.

How fast do you respond to a Valkey production outage?

P1 emergencies — instance down, writes rejected, cluster unavailable — 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, not best-effort targets.

Can you migrate us from Redis to Valkey without downtime?

In most cases, yes. We start with a compatibility assessment across your command usage, Lua scripts, module dependencies, and client SDK versions, because that is where surprises live rather than in the data itself. Migration then runs as replication or RDB transfer with key-level validation, followed by a shadowed cutover with a rehearsed rollback. Deployments using modules that have no Valkey equivalent are the exception, and we identify those in the assessment rather than mid-cutover.

Our latency spikes are intermittent and we can't reproduce them. Can you find that?

That is the most common Valkey engagement we take. Intermittent spikes almost always trace to something periodic rather than something load-driven: a fork for an RDB snapshot or AOF rewrite, transparent huge pages amplifying copy-on-write, an expiry wave, or a scheduled client running an expensive command. We correlate LATENCY HISTORY, SLOWLOG, fork timings, and host-level metrics on a single timeline, which usually turns an unreproducible problem into a schedule.

Can you help with our Broadcom Tanzu Valkey licensing and true-up?

Yes. As Broadcom's VMware Expert Advantage Partner of the Year for the Americas, we size Tanzu Valkey subscriptions against your deployed node and core counts, reconcile them with purchased entitlements, flag true-up exposure before an audit does, and negotiate renewal and multi-year terms. Licensing quotes come back within 24 hours, from the same team that sizes your cluster.

How is AceMQ Valkey support priced?

Support is priced as an annual contract based on your deployment size, required SLA tier, and coverage hours — not per incident or per ticket. Calling us during an outage never carries a cost decision. Contact us for a quote; we turn them around within 24 hours.

Tanzu Valkey Support

24/7 Tanzu Valkey Support with a 15-Minute Emergency SLA

AceMQ is Broadcom's VMware Expert Advantage Partner of the Year for the Americas. Valkey inherits Redis's operational surface exactly — fork stalls during RDB snapshots, transparent huge pages wrecking tail latency, evictions that never fire, replicas resyncing in a loop. Our engineers have been debugging that surface since long before the fork, and every ticket reaches a named senior engineer who knows your topology.

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

Escalation Path

Your first hour of a Tanzu Valkey 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 Tanzu Valkey 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

Tanzu Valkey problems we fix every week

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

Symptom you're seeingWhat we check firstTypical resolution

Periodic latency spikes of hundreds of milliseconds that line up with the save schedule

What we check firstlatest_fork_usec in INFO against the RDB and AOF-rewrite schedule. Fork cost scales with page-table size, not dataset size, and the fork blocks the single event loop — so a large instance can stall every client for half a second on a schedule nobody remembers setting.

Typical resolutionUnder 2 hours

Tail latency far worse than the dataset size should produce, with no obvious cause

What we check firstTransparent huge pages at the OS level. THP inflates copy-on-write cost after a fork by orders of magnitude, and it is enabled by default on most distributions — this is a one-line host change that resolves latency problems teams have chased for months.

Typical resolutionUnder 1 hour

Writes rejected with an OOM error while memory usage looks like it should be evicting

What we check firstmaxmemory-policy against actual TTL coverage on the keyspace. noeviction rejects writes by design, and volatile-* policies only consider keys that carry a TTL — with mostly persistent keys there is nothing eligible to evict, so the instance fills and stops accepting writes.

Typical resolutionUnder 1 hour

Replicas repeatedly disconnect and fall back to a full resync

What we check firstclient-output-buffer-limit for the replica class and repl-backlog-size against your write throughput. If the replica's output buffer overruns mid-sync the primary drops it, and the resulting full resync generates yet more write load — a loop that gets worse under exactly the traffic that triggered it.

Typical resolution1–3 hours

Cluster resharding stuck with slots left in migrating or importing state

What we check firstCLUSTER SETSLOT state on both source and target plus the keys still open in the slot. A large collection key migrated with too short a timeout leaves the slot half-moved, and the cluster stays in that state until the slot is explicitly resolved on both ends — retrying the reshard makes it worse.

Typical resolution2–4 hours

One node's CPU pegged at 100% on modest operations per second

What we check firstSLOWLOG and LATENCY HISTORY, then keyspace notification config and pattern subscriptions. A KEYS scan, an SMEMBERS over a large set, or a broad psubscribe fan-out all run on the event loop, so one expensive client can saturate a node the metrics say is barely loaded.

Typical resolutionUnder 2 hours

Reported memory far above the sum of stored key sizes

What we check firstmem_fragmentation_ratio and allocator statistics. Fragmentation after a large eviction or expiry wave leaves jemalloc holding pages it cannot return — activedefrag tuning usually fixes it, but the ratio also has to be read correctly, because a value under 1.0 means swapping and is a much more urgent problem.

Typical resolution1–3 hours

Resolution times reflect typical Tanzu Valkey 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

What's Included

Everything in your Tanzu Valkey support contract

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

Emergency Incident Response

Cache down, writes rejected, or a cluster stuck mid-reshard with production traffic on it. 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 persistence, eviction, or host-level change that prevents recurrence. Delivered as standard, not on request.

Latency & Memory Tuning

Fork and persistence strategy, THP and kernel parameters, eviction policy against real TTL coverage, fragmentation and defrag settings, hot key detection, and client-side pooling and pipelining.

Cluster & Failover Operations

Slot distribution and resharding, replica placement, Sentinel or cluster failover timing verified by actual chaos testing rather than assumed, and zero-downtime node addition and removal.

Redis to Valkey Migration

Command and protocol compatibility assessment, client SDK verification, RDB-based data movement with key-level validation, and cutover with traffic shadowing and a rehearsed rollback.

Broadcom Licensing & Entitlement

As Broadcom's Expert Advantage Partner of the Year, we handle Tanzu Valkey subscription questions alongside the technical ones: entitlement reconciliation, true-up exposure, renewal terms, and quotes inside 24 hours.

Anywhere You Run It

We support Tanzu Valkey wherever it's deployed

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

Kubernetes & OpenShiftTanzu Platform / Cloud FoundryVMware vSphere & TanzuAWS (EC2, EKS)Microsoft Azure (AKS)Google Cloud (GKE)Bare metal & on-premiseHybrid cloudAir-gapped / no outbound accessValkey Cluster modeSentinel-managed deploymentsRedis 6.x / 7.x estates in migration

Why AceMQ

What you get that you don't get elsewhere

Broadcom Expert Advantage Partner of the Year

AceMQ holds Broadcom's top VMware partner award for the Americas in 2025. That gives you an escalation path into Tanzu engineering for genuine product defects, and one team handling both your support and your Valkey subscription.

Named Engineers, Zero Cold Start

The same senior engineers stay on your account. They know your shard layout, your persistence choice, and your access pattern — so a P1 starts with diagnosis instead of you describing your topology while writes are failing.

No Tier-1 Triage Layer

You reach a senior Valkey engineer directly by phone, email, or Slack. No help desk collecting information to pass along, no escalation approval between you and someone who can read a LATENCY report.

Host-Level, Not Just Config-Level

Most Valkey latency problems are kernel problems: transparent huge pages, overcommit settings, swap, NUMA placement, or a noisy neighbour on shared storage. We diagnose down to the host, because that is where the answer usually is.

Genuine Follow-the-Sun Coverage

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

Proactive, Not Just Reactive

Quarterly health checks plus shared intelligence across our support base. When a version-specific bug surfaces on one customer's cluster, every affected customer hears about it before it reaches their production.

FAQ

Tanzu Valkey support questions

A Cache Outage Is an Application Outage

Whether you need emergency response tonight, an intermittent latency spike finally explained, or a Redis-to-Valkey migration planned properly, AceMQ staffs every engagement with a named senior 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.