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

A third party can support it. Open-source Redis and Valkey have no vendor support contract attached, so production support comes from an independent provider or your own team. AceMQ supports open-source Redis, Valkey, Redis Enterprise deployments and the managed services (ElastiCache, Azure Cache for Redis, Memorystore) under one contract. What a third party cannot do is ship a patched Redis Enterprise binary; product defects in the commercial distribution still go to Redis Ltd, and we work that escalation alongside you.

A Redis support contract with AceMQ covers 24/7 incident response with a 15-minute emergency SLA, named senior engineers rather than a ticket queue, written root cause analysis on every P1, latency and memory investigation, Cluster and Sentinel failover problems, persistence and backup review, security and CVE advisory, and upgrade or Valkey migration planning. It covers the Redis you run, on the version you run, wherever it is hosted.

Redis Ltd supports Redis Enterprise and Redis Cloud under its own subscriptions. The cloud platforms support their managed offerings — ElastiCache, Azure Cache for Redis, Memorystore — inside those platforms. Independent firms such as AceMQ support open-source Redis, Redis Stack and Valkey on any infrastructure: 24/7 cover, a 15-minute emergency SLA, and a named senior engineer for latency, memory, replication and failover problems. Which one fits depends on where Redis runs and whether you need a vendor licence or an engineer.

Redis is an in-memory data store used for caching, session storage, rate limiting, queues, leaderboards, real-time data and increasingly as a vector store for AI retrieval. Its data structure primitives — strings, hashes, sorted sets, streams — are what let a single instance serve sub-millisecond reads at very high throughput. What breaks is rarely Redis itself: it is an eviction policy that does not match the access pattern, a key design that turns an O(1) lookup into an O(N) scan, a fork stall during snapshotting, or a failover the client library never noticed. Those are the failures a Redis support contract exists to cover.

It is again, with a caveat. Redis moved off the permissive BSD license in version 7.4 to a dual source-available model (RSALv2 and SSPLv1), which is what prompted the Valkey fork under the Linux Foundation. From Redis 8, Redis Open Source added the OSI-approved AGPLv3 as a third option, so Redis 8 and later are available under RSALv2, SSPLv1 or AGPLv3. Redis 7.2 and earlier remain BSD, and Valkey stays BSD. For teams running Redis internally, none of these licenses restricts use; the differences matter mainly to vendors embedding or offering Redis as a service. For most teams operating Redis internally the practical question is not the license but who patches your version when something is found in it. AceMQ supports both Redis and Valkey and will tell you plainly whether a migration is worth doing for your workload rather than assuming it is.

Because the server usually is healthy. Connection errors on an otherwise idle Redis almost always trace to the client side: a connection pool sized below peak concurrency, a client library that has not refreshed topology after a failover and is still writing to a demoted primary, an idle timeout closing pooled connections underneath the application, or TLS handshake cost under connection churn. Diagnosing it means correlating client-side pool metrics against server-side connected_clients and rejected_connections rather than restarting the node and hoping.

A Redis health check is an assessment of the running deployment rather than a checklist against documentation. It covers memory headroom and eviction behaviour under real traffic, key and data structure design, persistence configuration against your actual durability requirement, high availability topology and failover validation, client library and connection pooling configuration, security posture and CVE exposure for your version, and performance tuning opportunities visible in latency percentiles. You get written findings with severity, not a dashboard screenshot.

Yes. Redis is widely used as a vector database for retrieval-augmented generation, where sub-millisecond similarity search sits on the critical path of every request. The operational profile is different from caching: index build cost, memory footprint per vector, and query latency under concurrent writes all become the constraint, and Redis Search behaviour under high-frequency writes is a failure mode we have diagnosed in production. The same support contract covers it.

Redis support covers 24/7 emergency incident response with a 15-minute SLA, written root cause analysis on every P1, latency and memory tuning, data model review, security and CVE advisory, HA topology design, and upgrade or migration support. Every ticket is handled by a named senior engineer assigned to your account. There is no first-line triage layer and no per-incident charge.

Yes. We support Amazon ElastiCache and MemoryDB, Azure Cache for Redis and Azure Managed Redis, Google Cloud Memorystore, and Redis Enterprise alongside self-managed deployments. Managed Redis removes node provisioning but not the failure modes that cause incidents — eviction policy, key design, O(N) commands, fork stalls, and client-side failover handling all remain yours. We work from parameter groups, event logs, and engine-level metrics where shell access is not available.

P1 emergencies — Redis unresponsive, a cluster with uncovered slots, a failover that stranded your clients — 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 commitments, not best-effort targets.

Yes, this is one of the most common reasons teams call us. Unexplained latency in Redis is nearly always one of four things: a fork stall during RDB save or AOF rewrite, transparent huge pages inflating that fork's copy-on-write cost, an O(N) command blocking the single-threaded command loop, or disk fsync latency under appendfsync always. We isolate which using LATENCY, SLOWLOG, and kernel-level evidence rather than changing settings and watching.

All three topologies. Cluster brings slot management, resharding, and cross-slot command constraints. Sentinel brings quorum sizing and the client-side awareness problem that causes split-brain writes to a demoted primary. Standalone with a replica has its own resync behavior. Each fails differently, and the right topology for you depends on your write volume and consistency requirements, not on which is newest.

Yes. We support Valkey as well as Redis across licensing changes, including advising on whether a migration is worth doing for your workload. The operational failure modes are largely shared today, so the same diagnostic depth applies. Where behavior has genuinely diverged between forks, we will tell you specifically where rather than treating them as interchangeable.

Both, and the second half is the one that catches teams out. RDB snapshots and AOF each fail differently under load — RDB forks and can double memory on a write-heavy instance, AOF grows until rewrite and can leave you restoring hours of commands. We review which persistence mode fits your durability requirement, size the headroom the chosen mode actually needs, and test a restore against real data rather than assuming the file is good. Most estates we inherit have backups running and have never restored one; that is the gap worth closing before an incident finds it for you.

High availability keeps you running when a node fails: Sentinel or Cluster failover, replica placement, and how clients behave during the election. Disaster recovery is what happens when the whole environment is gone — cross-region replication, a documented recovery procedure, and an RPO and RTO you have measured rather than assumed. They are separate designs and a sound HA setup tells you nothing about recovery time. Support covers reviewing both, including the failover behaviour your client libraries actually exhibit, which is frequently where the real recovery time hides.

Yes to both. A security review covers ACLs and user separation, TLS configuration, whether the instance is reachable from anywhere it should not be, dangerous commands left enabled, and the protected-mode and bind settings that account for most exposed Redis in the wild. On monitoring, the signals that predict incidents are memory fragmentation ratio, eviction and expiry rates, replication lag, blocked clients and connection churn — not just whether the process is up. We define what to alert on and review what you already collect; on managed engagements we run it. Findings come as a written report with severity and remediation.

Start by separating real growth from fragmentation and from keys that never expire. We compare used_memory with used_memory_rss, check the fragmentation ratio, sample the keyspace for large keys and keys without a TTL, and look at client output buffers and replication backlog, which are common hidden consumers. True leaks in the Redis software are rare. The usual findings are an eviction policy that does not match the workload, a developer pattern that writes without expiry, or a big key that grew unnoticed. The fix is then a configuration change, an application change, or both, and we tell you which.

Yes. Data migration between deployments, whether that is self-managed to a managed service, Redis to Valkey, or open source to Redis Software, is done with replication-based cutover so the application sees seconds of interruption, not a maintenance window. We also help teams automate the estate: Terraform and Helm for provisioning, a pipeline for configuration changes, and continuous checks on persistence, replication and memory headroom so problems surface before they page anyone. Version upgrades follow the same replica-first method and are rehearsed before production.

Yes. In Redis Open Source, version 7.0 and everything before 6.2 are past end of life, 6.2 is supported until 1 April 2027, and 7.2 and 7.4 until 1 December 2029. AceMQ supports the version you actually run and plans the upgrade. Where you need security patches on a version you cannot yet leave, AceMQ's OSSeva platform backports CVE fixes to Redis 6.2.x and 7.0.x, which stay BSD licensed.

Support is an SLA over Redis your team runs: you hold the pager and call us when something breaks. Managed Redis services means AceMQ runs Redis or Valkey on your infrastructure or on AceMQ infrastructure, owning monitoring, patching, upgrades, failover, capacity and on-call. Teams that want to keep ownership choose support; teams that want Redis to stop being their problem choose managed services.

Yes. AceMQ works on Redis 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.

Every AceMQ proposal is tailored to your requirements: your Redis 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 Redis is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.