What Redis Support Actually Covers (and Doesn't)

Most Redis incidents are not really Redis failing. They are Redis behaving exactly as configured, in a way the application did not expect.

That single fact is why scope matters more than response time on a Redis support contract — and scope is the clause almost nobody reads until the incident that falls outside it.

Availability and topology. Standalone with a replica, Sentinel, and Cluster mode each fail differently — slot management and cross-slot constraints in Cluster, quorum sizing and client awareness in Sentinel, resync behaviour in standalone. All three should be named in scope, not assumed. See high availability patterns.

Memory and eviction. Behaviour at maxmemory, policy selection, and diagnosing growth that does not track key count — covered in memory growth without more keys.

Replication and failover. Lag under write load, and failovers that complete cleanly rather than half-way.

Persistence. Configuration and its latency cost, which is a frequent and non-obvious source of spikes.

Client connection diagnosis, and escalation with a response commitment by severity — see Redis incident response.

This deserves its own section because it causes more disputes than any other single thing.

Redis can be a cache or a datastore. The configuration differs — eviction policy, persistence, replication guarantees — and the two are not interchangeable. An enormous share of production incidents are an application treating a cache-configured Redis as durable storage and discovering, during an eviction event, that it never was.

Support will identify that in minutes. It will not decide for you whether the answer is to change the eviction policy, add persistence, resize memory, or fix the application's assumption — that is an architecture decision with cost implications on your side. A good provider raises it during onboarding rather than during the outage, which is the practical argument for a contract that includes design review.

Client timeouts against a healthy server. Usually connection pool exhaustion or a blocking command, not the server at all. See client timeouts with a healthy server. A provider who declines this because "Redis is fine" is technically right and practically useless.

Latency spikes from persistence. Redis is doing what it was told to do; the impact is real.

A failover the client library did not follow. The server failed over correctly. The application kept writing to a demoted node.

Slow commands on the hot path. A single expensive operation blocking the event loop is an application pattern with a Redis symptom.

In all four the useful provider helps first and attributes afterwards. Establish which kind you have before you need to know.

Take three Redis incidents you have genuinely had and ask a prospective provider, for each: covered, excluded, or grey? The answers are useful; the way they answer is more useful still.

Then confirm two things explicitly. Whether design and architecture review is included or billable — if it is billable, nobody will ask, and you lose the cheapest prevention available. And whether the provider will hold your topology and runbooks in advance, because a provider onboarding during an incident is starting from zero at the worst possible moment.

AceMQ supports production Redis and Valkey estates with design review and advisory access inside the contract. See how we support Redis, or get in touch.