Redis Production Readiness Checklist 2026: 30 Checks

Run the checks in order on the instance as it will run in production, and treat any row that fails as a go-live blocker until you have decided to accept the risk in writing. The first three groups cover what loses data or takes the instance down, so they come first. Every row comes from one of two places: a setting the Redis documentation tells you to apply, or a failure pattern we see repeatedly in support work. Commands and defaults were read from redis.io on 28 October 2026: the administration, persistence, replication, Sentinel, scaling, security, ACL and client-handling pages. Where a row is our own advice rather than a documented rule, it says so.

Most first outages are memory: a full instance with the default eviction policy, or a fork at save time that doubles usage. These seven checks set the ceiling and the headroom around it.

From our engagements. A pattern we see in support work is a maxmemory chosen at go-live that no one revisited as the dataset and replication buffers grew, so the first outage arrives at the busiest hour. On a real-time screen-sharing platform, a misconfigured 7 GB memory ceiling forced evictions well before the hardware limit, and Redis Search slowed under high-frequency writes; correcting the ceiling and rotating degraded instances restored stability (the engagement).

Persistence decides how much you lose when Redis stops, and backups decide whether you can recover when the disk does not survive. The Redis documentation is blunt about it: no backups means a huge risk of data disappearing.

The empty-restart failure in check 10 costs nothing to prevent: one line in the runbook says either that the primary persists or that it is never restarted automatically.

Replicas protect against a lost node only if the quorum is placed so it survives that loss and clients follow the new primary. Redis replication is asynchronous, so acknowledged writes can still be lost in a failover, and the point of these seven checks is to bound that and to prove the recovery time.

Check 18 is the one most teams skip. Kill a primary with clients connected and watch how long promotion takes, whether clients reconnect to the new primary or keep writing to a stale one, and what the application does with the writes in flight. The time you measure is your real recovery time.

Redis is built to be reached by trusted clients inside trusted environments, so a safe deployment is one where untrusted traffic cannot reach the port and every client has the least access it needs. The default user, out of the box, can run every command on every key with no password.

The documentation marks the older rename-command method as deprecated in favour of ACL rules, so use ACLs for check 23.

Redis serves commands one at a time, so one slow command or one exhausted connection pool looks like an outage while the server reports healthy. These four checks make that visible.

From our engagements. On .NET microservices behind a banking application, AceMQ traced intermittent 10-second Redis connection timeouts to the clients: connection pool exhaustion and misconfiguration, and synchronous blocking patterns, not Redis capacity (the timeout case). A second pattern we see is latency that climbs under sustained load on small cloud cache nodes sized for a test and left in production.

The instance stays production-ready only if someone is told when it drifts and knows the next step. These three checks cover monitoring, the upgrade path and the escalation route.

Supported versions and dates change, so check them against the Redis end-of-life table and keep it with the runbook.

If one or two checks fail, fix them yourself: most are one setting and a test. If checks 16 to 18 or 8 to 12 fail, treat go-live as blocked, because those are the ones that lose data or leave you without a tested way back. AceMQ has been in business for more than 10 years, supports 160+ customers, and handles 40+ Sev 1 incidents a year. A Redis health check reads these signals on your deployment, ranks the findings by what will fail first and ends in a written fix list. 24/7 support carries a 15-minute emergency response, and a quote request is answered within 1 hour.

Where we are not the right fit. If your Redis is a small cache on a managed cloud service and your team is comfortable owning it, the checklist above is enough and you do not need us. Several rows, such as the host settings in checks 4 to 6, do not apply to a managed service at all, and the cloud provider's support tier covers the service itself. Regular support from AceMQ is priced at $24,000 to $72,000 a year by SLA, scope and deployment, with aggressive multi-technology discounts, so it suits production estates where an outage costs more than that.