Redis 24/7 Incident Response: What Actually Happens at 3am

Every provider says 24/7. The phrase covers two very different products, and the difference only becomes visible during an outage.

One version is an engineer who can act on your cluster, reachable at any hour, with a stated response commitment and a named escalation path. The other is a ticket queue that accepts submissions at any hour and produces a first human response during business hours. Both are marketed identically. Find out which you are buying before you need it.

The first job is classification, because Redis is very often the symptom rather than the cause. The questions, roughly in order:

Is the instance reachable and responding? A server that answers PING is a different incident from one that does not.

Is this memory pressure? Whether maxmemory has been reached and eviction is running. Applications that treated Redis as durable discover this at exactly the wrong moment — see choosing an eviction policy.

Has a failover occurred, or failed to? A failover that half-completed — clients pointed at a node that is no longer primary — presents as a mystery rather than an outage. See Redis high availability patterns.

Is replication healthy? Lag under write load changes both the diagnosis and what is safe to do next.

Is the server actually fine? Client-side timeouts against a healthy Redis are common and lead investigations in entirely the wrong direction — see client timeouts with a healthy server.

Getting this classification right in the first few minutes is what determines whether the next hour is productive or wasted.

A response commitment is a promise to make contact and begin work within a stated window. That is a real, verifiable promise.

Resolution depends on what is wrong, and nobody can commit to resolving a problem they have not diagnosed. A provider offering resolution-time guarantees is either excluding most real incidents in the small print or making a promise they will not keep.

The commitments worth having in writing are response time by severity, escalation timing — when does this stop being one engineer and become a team — and who specifically gets involved as severity rises.

An incident is the worst possible time to onboard a support provider. Each item below costs about an hour in advance and roughly an hour of outage if skipped.

Access and topology in advance. Node layout, replication topology, sentinel or cluster configuration, client connection patterns. An engineer starting from zero at 3am is starting from zero.

Monitoring history, not just live metrics. The useful question during an incident is what changed, and that requires a baseline.

An agreed escalation path. Who on your side can authorise a failover, a restart, or a configuration change under pressure.

Runbooks the provider has actually read. Including the undocumented parts — the application that reconnects badly, the job that runs at 2am.

A Redis health check is the usual way to establish all of this at once, and it tends to remove a few future incidents while it is at it.

Four questions, and the vagueness of the answers is itself the answer.

What happens at 3am on a Sunday? Not the policy — the mechanics. Who answers, how, and how quickly.

What is the response commitment by severity, in writing?

Will you hold our topology and runbooks in advance? A provider unwilling to onboard before an incident will be onboarding during one.

Who is the escalation, and when do they arrive?

AceMQ supports production Redis estates, including out of hours. If you want the topology and escalation path agreed before you need them, see how we support Redis or get in touch.