01
Emergency Incident Response
Primary down, writes refused, failover not completing or a cluster stuck mid-reshard. A senior engineer joins a live bridge within 15 minutes, 24/7, with access to diagnose rather than a ticket acknowledgement.
Valkey Support
24/7 Valkey Support with a 15-Minute Emergency SLA
Last reviewed by Scott Sternloff
Enterprise support for open source Valkey wherever it runs: self-managed on virtual machines or Kubernetes, on premises, or alongside Amazon ElastiCache, Google Cloud Memorystore and Tanzu for Valkey. Valkey is a Linux Foundation project with no single vendor selling a support tier, so AceMQ provides the production support contract: a named senior engineer, a 15-minute response for P1 incidents, and the same team for Valkey and Redis.
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 Valkey consulting and services.
Customers
Partners
Incident Triage
Valkey problems we fix every week
These are real symptoms from real Valkey production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Monitoring or a client library reports Redis 7.2.4, though the cluster runs Valkey 8 or 9 | That is by design. Valkey keeps reporting a Redis 7.2.4-compatible version in the redis_version field of INFO so existing clients and tools keep working, and records its own release in valkey_version. Tools that decide behaviour from the Redis version, and clients that expect commands added to Redis after the fork, are where surprises appear, so test the exact driver and tool versions before cutover. | Under 2 hours |
| CPU looks idle on most cores but throughput has stopped climbing after an upgrade to Valkey 8 | io-threads against core count and workload. Valkey 8.0 reworked I/O threading and 8.1 moved more work onto the I/O thread pool, so the setting that suited 7.2 is rarely right afterwards. Too few threads leaves throughput on the table; too many on a small host competes with the main thread. | Under 2 hours |
| Resharding a cluster leaves slots stuck in a migrating or importing state | Which migration path ran. Before Valkey 9.0, slots moved key by key, and a large collection with too low an input buffer limit can block the move halfway. Valkey 9.0 adds atomic slot migration, which moves a whole slot at once and is the recommended method. A stuck legacy migration has to be resolved on both nodes before anything is retried. | 2 to 4 hours |
| Replicas drop and fall back to a full resync during a rolling upgrade | Upgrade order and version gap. Valkey's guidance is to upgrade replicas before primaries and not to run a cluster on mixed minor versions longer than the rollout takes. Then check client-output-buffer-limit for replicas and repl-backlog-size against write volume, because a full resync under load can loop. | 1 to 3 hours |
| Writes rejected with OOM errors while the instance should be evicting | maxmemory-policy against the TTLs actually set. volatile policies only evict keys that carry an expiry, so a keyspace of persistent keys has nothing eligible and the instance stops accepting writes. On Valkey 9.0, hash field expiration (HEXPIRE and related commands) changes how much of a hash can age out, which is worth using where the data model allows it. | Under 1 hour |
| Periodic latency spikes that line up with snapshots | latest_fork_usec in INFO against the RDB and AOF rewrite schedule, then transparent huge pages on the host. The fork blocks the event loop and its cost grows with memory size, and THP multiplies copy-on-write work after the fork. Both are host-level fixes, not Valkey settings. | Under 2 hours |
Resolution times reflect typical Valkey engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
Everything in your Valkey 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 configuration, client or host change that stops it recurring.
- 03
Redis to Valkey Migration
Command and client compatibility review, replication-based or RDB data movement with key-level validation, and a cutover with a rehearsed rollback. We also tell you plainly when staying on Redis is the better call.
- 04
Upgrades and Performance
Upgrades from Valkey 7.2 to 8.x and 9.x planned per release notes, I/O thread tuning, memory and eviction policy, persistence strategy, and client pooling and pipelining.
- 05
Cluster and High Availability
Valkey Cluster slot layout and resharding, including atomic slot migration on 9.0, replica placement, Sentinel deployments, and failover tested with clients connected.
- 06
Security Patching and Older Versions
CVE assessment against the versions you run. Valkey 7.2 and 8.x estates that cannot upgrade yet can get backported security fixes through AceMQ's OSSeva platform.
Why AceMQ
What you get that you don't get elsewhere
A Support Contract Valkey Does Not Ship With
Cloud services support their own managed Valkey, and the project offers community channels. Self-managed and on-premises Valkey needs a contract with someone accountable. That is what we provide, with named engineers who know your topology.
No Tier-1 Triage Layer
You reach a senior engineer directly by phone, email or Slack. Nobody collects details to pass along while writes are failing.
Valkey and Redis, One Team
Most estates run both during and after a migration. One contract covers Redis and Valkey, so an incident never stalls on which engine it belongs to.
Follow-the-Sun Coverage
Engineers across 26+ countries and every time zone, so a 3am eviction storm reaches someone who is already at work.
We support Valkey wherever it's deployed
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
- Self-managed on Linux virtual machines
- Kubernetes (EKS, AKS, GKE, OpenShift)
- On-premises and air-gapped data centres
- Amazon ElastiCache for Valkey
- Google Cloud Memorystore for Valkey
- Tanzu for Valkey
- Valkey Cluster
- Valkey Sentinel deployments
- Valkey 7.2, 8.0, 8.1, 9.0 and 9.1
- Mixed Redis and Valkey estates
Version coverage
Valkey versions we support
The Valkey project gives each minor version three years of maintenance support, with patch releases for bugs and security fixes, and extends security fixes to five years for the last minor version of each major line.
| Valkey version | First released | Upstream maintenance ends | AceMQ coverage |
|---|---|---|---|
| Valkey 9.1 | 19 May 2026 | 19 May 2029 | 24/7 support |
| Valkey 9.0 | 21 October 2025 | 21 October 2028 | 24/7 support |
| Valkey 8.1 | 31 March 2025 | 31 March 2028 (security fixes to 31 March 2030) | 24/7 support |
| Valkey 8.0 | 15 September 2024 | 15 September 2027 | 24/7 support and upgrade planning |
| Valkey 7.2 | 16 April 2024 | 16 April 2027 (security fixes to 16 April 2029) | 24/7 support, plus CVE fixes backported through OSSeva |
Source: the Valkey releases and versioning page on valkey.io, checked 7 October 2026. Redis estates are covered on the Redis support page.
Escalation Path
Your first hour of a Valkey outage
Every tier reaches a senior Valkey 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 Valkey support cost?
AceMQ Valkey 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, Amazon ElastiCache, Google Memorystore 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
Valkey problems we've already solved
Valkey support, migration and patching work from AceMQ. Each card links to the full write-up: the Valkey estate, what AceMQ diagnosed or changed, and the result.
Redis to Valkey Migration Under Memory Pressure
Digital Collaboration Platform
A production Redis cluster was crashing under memory growth traced to its full-text index rather than to the workload. AceMQ diagnosed the leak, stabilized the cluster, and mapped the Valkey migration path.
Valkey
Redis
KubernetesValkey Cluster Resharding Stuck Mid-Migration
Regional Payments Processor
A Valkey Cluster resharding ahead of a seasonal peak stalled with slots left in migrating and importing states. AceMQ resolved the slots on both nodes, finished the move in controlled batches and set up support for the next one.
ValkeyKubernetes
PrometheusValkey 7.2 Security Patching Without a Forced Upgrade
Benefits Administration Provider
A regulated provider could not move its on-premises Valkey 7.2 clusters for another year. AceMQ assessed each security advisory against its configuration and backported the fixes through OSSeva.
Valkey
LinuxRedis SentinelRedis to Valkey Compatibility Assessment Across 41 Instances
European Telecom Operator
A telecom operator wanted to move its Redis estate to Valkey but did not know which instances could move cleanly. AceMQ assessed commands, scripts, modules and clients instance by instance and ordered the migration.
ValkeyRedisKubernetes
Support options
Four stages of Valkey support.
AceMQ offers Valkey support in four stages, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for Valkey your team runs, proactive monitoring that catches upgrade, memory and failover gaps first, managed Valkey on your own infrastructure, and fully managed Valkey on AceMQ infrastructure. Valkey 7.2 to 9.1 are covered, with CVE fixes for 7.2 backported through OSSeva.
- Stage 1
Valkey 24/7 Support & Incident Management
You run it, we back you up
- Stuck slot migrations and cluster failover resolved on both nodes
- Replica resync loops and full-sync storms traced to buffer limits
- OOM rejections traced to eviction policy against real TTL coverage
Best for: Teams that run self-managed Valkey on VMs or Kubernetes, or alongside ElastiCache and Memorystore, and need senior cover at 3am.
- Stage 2
Valkey 24/7 Support with Proactive Monitoring
You run it, we watch it with you
- Upgrade plans from 7.2 to 8.x and 9.x checked against release notes and your clients
- io-threads, memory, eviction and persistence settings reviewed on real traffic
- Failover and rolling-upgrade rehearsals with clients connected
Best for: Estates that are moving between Valkey versions, or off Redis, and want the surprises found in a review.
- Stage 3
Managed Valkey on Your Infrastructure
We run it in your cloud or data centre
- Memory, eviction, replication and cluster-slot monitoring with paging
- Replica-first rolling upgrades rehearsed before production
- Cluster and Sentinel failover tested after every change
Best for: Regulated teams that must keep Valkey inside their own boundary but do not want it on their own rota.
- Stage 4
Fully Managed Valkey on AceMQ Infrastructure
We host it and run it, as a service
- Topology sized from your keyspace, throughput and durability need
- Redis to Valkey cutover planned and rehearsed before traffic moves
- Backups restored and timed, not only taken
Best for: Teams that want Valkey, or a move off Redis, without staffing a platform rota.
| Who does what | Stage 1 24/7 support | Stage 2 Proactive monitoring | Stage 3 Managed, your infrastructure | Stage 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Valkey 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 Stage can start as an ad hoc engagement or an annual partnership, and you can move up or down a Stage as your team changes.
One partner for Valkey
Everything else AceMQ does for Valkey.
Support is one part of what AceMQ does for Valkey. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
- ConsultingValkey consulting and services
- Managed servicesManaged Valkey services
- MigrationValkey migration
- LifecycleEnd-of-life software support
- Enterprise supportOpen source support across your whole stack
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 52 technologiesShow fewer
Related services
Who offers Valkey support?
It depends where Valkey runs. AWS supports ElastiCache and MemoryDB for Valkey, Google Cloud supports Memorystore for Valkey, and other hosting providers support their own managed services. For self-managed, Kubernetes and on-premises Valkey, support comes from independent providers. AceMQ covers Valkey and Redis under one 24/7 contract with a 15-minute emergency SLA. The Linux Foundation project offers community channels, not a support contract.
What is Valkey, and why are teams moving to it?
Valkey is an open-source, in-memory key-value data store used as a cache, session store, message broker and primary database, and it speaks the same protocol as Redis, so existing Redis clients connect to it unchanged. It exists because Redis changed its licence in 2024: the Linux Foundation forked Redis 7.2.4 to keep a BSD-licensed version, with backing from AWS, Google Cloud and Oracle. Teams adopt it to avoid licensing changes, because AWS ElastiCache and Google Cloud Memorystore now offer it as a managed engine, or because new releases such as Valkey 8 and 9 add threading and cluster improvements.
What does AceMQ Valkey support include?
24/7 incident response with a 15-minute SLA for P1 incidents, a written root cause analysis for every P1, upgrades and performance tuning, cluster and high availability operations, Redis to Valkey migration, and security patching advice for the versions you run. Every ticket goes to a named senior engineer. There is no per-incident charge.
Is Valkey open source, and who maintains it?
Yes. The Linux Foundation launched Valkey in March 2024 as a fork of Redis 7.2.4, and it remains under the BSD 3-clause licence. It is developed by a community of contributors under the project's technical steering committee rather than by one company.
Which Valkey versions are supported?
The project currently maintains Valkey 7.2, 8.0, 8.1, 9.0 and 9.1, each with three years of maintenance support from its first release, and extended security support for the last minor version of each major line. AceMQ supports all of them, and older 7.2 and 8.x deployments can get backported CVE fixes through OSSeva while an upgrade is planned.
Do you support Valkey on Amazon ElastiCache or Google Cloud Memorystore?
Yes, for everything the cloud provider does not own. AWS and Google run the nodes, but key design, eviction and memory policy, client configuration, cluster sizing and most incident causes remain yours. We work alongside the provider's support on those, and on migrations into or out of the managed service.
Do you support Tanzu for Valkey?
Yes. Teams running Broadcom's Tanzu for Valkey get the same 24/7 engineering support, and as Broadcom's Expert Advantage Partner of the Year for the Americas we also handle Tanzu subscriptions. The details are on our Tanzu Valkey support page.
Can you migrate us from Redis to Valkey without downtime?
Usually, yes. We start with a compatibility review of commands, Lua scripts, modules and client library versions, because that is where problems appear, not in the data. The move then runs by replication or RDB transfer with key-level validation and a shadowed cutover with a rehearsed rollback. Workloads that depend on Redis modules or commands added after the fork are the exception, and the review finds them before the cutover does.
Can you run Valkey for us instead of supporting it?
Yes. Managed Valkey is part of our managed Redis service: AceMQ operates Valkey on your own infrastructure, including monitoring, patching, upgrades, failover and on-call, while the cloud account and data stay yours.
Can we work with AceMQ on Valkey without a long contract?
Yes. AceMQ works on Valkey 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 Valkey support or consulting cost?
Every AceMQ proposal is tailored to your requirements: your Valkey 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 Valkey is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Put Someone Accountable Behind Your Valkey
Reactive cover, proactive reviews, or AceMQ running Valkey for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
A senior Valkey engineer, not a sales queueQuote requests answered within 1 hourAd hoc engagements or an annual partnership
Production incident right now?Email a Valkey Architect
Get in Touch
Talk to a Valkey 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.