01
Memory and Eviction
maxmemory against host memory with headroom for overhead and forks, the eviction policy against the workload, fragmentation and allocator statistics, big keys, and client output buffers.
Redis and Valkey Health Check
Redis Health Check: Memory, Eviction, Latency and Failover Reviewed
Last reviewed by Scott Sternloff
A Redis health check is an engineer-led review of a running Redis or Valkey deployment against how it is actually used: memory ceiling and eviction, persistence, replication and Sentinel or Cluster failover, latency, clients, security, and whether the version is still supported. It takes one to four weeks, is quoted rather than list-priced, and ends in a written report, a prioritised fix list and a walkthrough with the engineer who did the work.
- checks across 7 areas on every deployment
- 20
- weeks from kickoff to walkthrough
- 1-4
- min emergency SLA on the support plan
- 15
Trusted for Mission-Critical Redis by Teams in Finance, Healthcare, Defense, Telecom, and More
Customers
Partners
Is This You?
You probably need this if…
- 01
Latency spikes at peak and nobody can say whether the cause is memory, a slow command, a fork or the client
- 02
Memory climbs toward the ceiling and the team is unsure what happens when it arrives
- 03
Redis runs on a burstable cloud instance and slows down under sustained write load
- 04
Failover has never been tested with real clients connected
- 05
An RDB save or AOF rewrite has coincided with a latency or memory spike
- 06
You are weighing Redis 8, Valkey or staying put, and need the facts about your own estate first
- 07
An audit or security questionnaire asks about authentication, TLS and exposure of the instances
- 08
The person who built the deployment has moved on
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Redis estate when the engagement closes.
Before
The memory limit and eviction policy were set at go-live, or never set, and nobody has checked them against peak load.
After
maxmemory, eviction policy and headroom reviewed against the real dataset, replication and fork overhead, with the ceiling and the failure mode written down.
Before
Latency complaints arrive as one-off incidents, each blamed on something different.
After
The structural causes named from the slow log and latency monitor: slow commands, forks, swap, fsync, burstable CPU or client pooling, each with a fix.
Before
Failover is documented but untested, and nobody knows what the clients do when the primary moves.
After
A failover test plan and the observed client behaviour, so the recovery time in the runbook is a measured number.
Before
The team knows the deployment is fragile but cannot rank the risks or size the work.
After
A prioritised plan in three buckets: change now, change before the next growth step, and fine as it is.
Scope
What's covered
- 02
Persistence
RDB, AOF or both against the recovery point you actually need, fork time and copy-on-write memory during saves, and disk and fsync behaviour on the volume Redis writes to.
- 03
Replication and Failover
Replica lag and backlog size, Sentinel or Cluster topology and quorum placement, and what clients do when the primary moves.
- 04
Latency
Slow log and latency monitor output, command patterns such as KEYS and large collections, intrinsic latency of the host, transparent huge pages, swap, and burstable CPU credits.
- 05
Clients and Connections
Pool sizing, timeouts and reconnect behaviour, connection counts against maxclients, and pipelining where round trips dominate.
- 06
Security
Authentication and ACL users, network exposure and protected mode, TLS, and which commands every application account is allowed to run.
- 07
Version and End of Life
The version in use against redis.io's support table, the upgrade path, the Redis 8 or Valkey question, and module memory such as search indexes.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 11 day
Intake and Scoping
We agree which instances are in scope, whether they are standalone, Sentinel or Cluster, Redis or Valkey, self-managed or on a cloud service, and the read-only exports we need. Delivery is remote, guided by your engineers over screen share. We take no access to your environment or code.
You receive
- Scope and instance list
- Export checklist: INFO output, configuration, slow log, latency report, replication state
- Incident history and known concerns collected
- Phase 21-4 weeks, by scope
Review
A senior Redis engineer works through the seven areas against your exports and metrics history, with your team in the room where a decision needs context. Findings are tested against real memory, latency and replication history, not a generic checklist.
You receive
- Inventory per instance and replica set
- Findings with evidence attached
- Failover test plan
- Phase 3Within a week of the review
Written Findings
The report, ranked by what is likely to fail first and under what conditions. Every finding carries the fix, the effort and the risk of leaving it.
You receive
- Written report
- Prioritised remediation list
- Monitoring gap analysis
- Phase 4At the end of the engagement
Walkthrough and Plan
A walkthrough with the engineer who did the work, then a sequenced plan your team can execute or hand to us. Remediation is scoped separately, so the report is useful whoever does the work.
You receive
- Findings walkthrough
- Sequenced plan: now, before the next growth step, fine as is
The 20 checks in a Redis and Valkey health check
Every health check works through the same 20 checks, grouped into seven areas. Each one names the evidence we read, so a second engineer can verify any finding. Everything here applies to Valkey as well, which shares the commands and statistics.
| Area | Checks | Evidence |
|---|---|---|
| Memory and eviction (4) | maxmemory set against host memory with headroom; eviction policy chosen on purpose; fragmentation and allocator statistics; key and value size distribution and client buffers | INFO memory, CONFIG GET maxmemory*, MEMORY STATS, MEMORY DOCTOR, memory usage on sampled keys |
| Persistence (3) | RDB, AOF or both against the recovery point you need; fork time and copy-on-write size during saves; fsync and disk behaviour | INFO persistence (latest_fork_usec, rdb_last_cow_size), appendfsync settings, disk metrics |
| Replication and failover (3) | Replica lag and backlog size; Sentinel or Cluster topology and quorum placement; failover test result and client reconnection | INFO replication, Sentinel or CLUSTER state, a rehearsed failover with clients connected |
| Latency (3) | Slow log and latency monitor; command patterns such as KEYS, large collections and Lua; host intrinsic latency, transparent huge pages, swap and burstable CPU | SLOWLOG GET, LATENCY DOCTOR, redis-cli --latency and --intrinsic-latency, OS settings |
| Clients and connections (2) | Pool sizing, timeouts and reconnects; connection counts against maxclients | INFO clients, CLIENT LIST, application client settings |
| Security (3) | Authentication and ACL users; network exposure and TLS; commands each account may run | ACL LIST, bind and protected-mode settings, TLS configuration |
| Version and end of life (2) | Version against redis.io's support table; upgrade path and module memory | INFO server, MODULE LIST, FT.INFO on search indexes where present |
Rule we hold
Redis's own documentation says that while saving an RDB file or rewriting the AOF, a write-heavy Redis can use up to twice the memory it normally uses. We size headroom for that peak, not for the dataset.
The setting that most often decides whether memory runs out gracefully is covered in Redis eviction policy: which to use
Typical findings and what the fix looks like
These are patterns the checks are built to catch. They are drawn from Redis's own documentation and the common ways production estates drift from it, not from a client report.
| Finding | Why it matters | Typical fix |
|---|---|---|
| maxmemory unset, or set at the size of the host | Redis's documentation advises an explicit maxmemory below free memory, for example 8 or 9 GB on a host with 10 GB free, so it returns errors instead of being killed. | Set maxmemory from the real overhead, and choose the eviction policy to match the workload. |
| Snapshot or rewrite fork on a busy instance | Copy-on-write can take memory toward double during a save, and a slow fork stalls the main thread (latest_fork_usec shows it). | More headroom, saves on a replica, or a different persistence setting. |
| Transparent huge pages enabled | Redis's latency guide says they cause big latency and memory use after a fork. | Disable them and restart Redis. |
| KEYS or large-collection commands in production | Redis is mostly single threaded, so one slow command delays every client behind it. | SCAN and its variants, smaller collections, and a replica for slow queries. |
| Burstable instance under sustained load | On ElastiCache T4g and T3 nodes, performance is gradually lowered to baseline when CPU credits run low. | Watch CPUCreditBalance and move to a non-burstable node type. |
| Small replication backlog or no failover rehearsal | Replicas fall back to full resyncs, and clients may keep writing to a demoted primary. | Size the backlog to memory, and run the failover with clients connected. |
| Version near or past end of life | Redis 8.0 reaches end of life on 1 December 2026 and 6.2 on 1 April 2027 on redis.io's table (checked 26 October 2026). | A planned upgrade, or a move to Redis 8.2 or Valkey. |
For the diagnostic process behind a finding, read what a Redis health check finds
What the Redis health check report contains
The report is written for the engineer who runs Redis and the manager who funds the fixes. This is the outline every report follows. It is a structure, not a client document, and it carries no customer data.
| Section | Contents |
|---|---|
| 1. Summary | The findings most likely to cause an outage or data loss, in plain language, with a risk rating for each. |
| 2. Inventory | Instances, replicas, Sentinel or Cluster layout, Redis or Valkey versions, host or cloud node types, persistence settings and modules. |
| 3. Findings register | One row per finding: severity, evidence, why it matters, the fix, effort and the risk of waiting. |
| 4. Memory and latency model | Ceiling, headroom and eviction behaviour at peak, and the sources of latency found. |
| 5. Failover and recovery | The failover test plan, observed client behaviour and the recovery time to put in the runbook. |
| 6. Remediation plan | Three buckets: change now, change before the next growth step, fine as it is. |
| 7. Appendix | Configuration exports and the checks run, so a second engineer can verify any finding. |
A report with a hundred undifferentiated observations has not done the hard part, which is ranking them. Ours puts the few findings that matter first and the rest in the appendix.
From health check to 24/7 Redis support
The health check is a standalone engagement and the usual first step before a support contract. The inventory, the findings and the monitoring gaps carry straight into onboarding, so the work is not repeated. Support runs on four tiers: Tier 1 is reactive support, Tier 2 adds proactive monitoring, Tier 3 is managed on your infrastructure and Tier 4 is managed on AceMQ's.
If your team keeps the pager and wants an engineer on call, see Redis and Valkey support
If you would rather hand Redis over entirely, see managed Redis and Valkey services
If the finding is that you should move to Valkey, the work is scoped as Redis to Valkey migration
Where this health check stops, and who it is not for
- Remote and read-only — We work from your exports and a screen share, guided by your engineers. We do not log in to your environment or touch your code.
- No application fixes — We tell you which client settings and patterns to change and why. Your developers make the change.
- Cloud services — On ElastiCache, Memorystore or Azure Managed Redis the provider owns node operations. We review memory and eviction settings you control, clients, access and latency symptoms, which remain yours.
- Not a penetration test — The security checks review configuration. They do not attack the instances.
- Remediation is separate — The report stands alone. If you want us to carry out the fixes, that is scoped and quoted as its own piece of work.
For the field patterns behind memory and latency problems, read the Redis memory and latency field guide
Customer Success
Real Redis Results
See how enterprises trust AceMQ for their most critical Redis workloads.
Clearing a Redis Memory Leak Without Taking Production Down
Real-Time Screen-Sharing SaaS Platform
Six live sessions over fourteen hours to find why a Redis cluster kept growing past its ceiling, and to stop it without a maintenance window.
RedisRedis SentinelContainersObservability
Middleware Architecture Assessment for Financial Trading
European Online Trading Platform
Independent architecture and performance review of RabbitMQ, Kafka, and Redis for an online trading platform.
RabbitMQ
KafkaRedisRedis Timeout Remediation for Fintech Microservices
Emsyne Technologies
AceMQ diagnosed Redis connection timeout issues causing service disruptions in a legacy fintech platform being modernized, identifying client-side resource exhaustion as the root cause and delivering a remediation plan for high-concurrency caching.
RedisRedis Enterprise Licensing and Architecture on OpenShift
UK Infrastructure Technology Firm
AceMQ advised a UK-based technology firm on Redis Enterprise licensing compliance and architecture validation as they migrated high-volume messaging infrastructure to OpenShift, handling millions of messages daily alongside RabbitMQ.
RedisRabbitMQ
OpenShiftMulti-Technology Support Including Redis for Global Trading Firm
DRW (Global Trading Firm)
AceMQ expanded its enterprise support agreement with global quantitative trading firm DRW to include Redis caching alongside RabbitMQ, providing L3 escalation support across the full messaging and caching technology stack.
RedisRabbitMQRedis Cluster Health and Architecture Assessment
Enterprise Technology Organizations
AceMQ's Redis Health and Architecture Assessment identifies cluster vulnerabilities, performance bottlenecks, and optimization opportunities before they become production incidents — delivering a prioritized remediation roadmap.
RedisRedis as Enterprise Data Layer for High-Throughput Fintech
Financial Services Provider
AceMQ helped a financial services provider architect Redis as a reusable enterprise data layer supporting session management, caching, and real-time data processing across millions of daily transactions.
RedisRedis Integration During Legacy .NET Application Modernization
Banking Technology Services Firm
AceMQ supported the integration of Redis as a modern caching layer during the migration of a legacy banking application from monolithic architecture to microservices, resolving concurrency and timeout issues during the transition.
Redis
FAQ
Questions about Redis health check
What is a Redis health check?
A Redis health check is a structured review of a running Redis or Valkey deployment against how it is used. It covers memory and eviction, persistence, replication and failover, latency, clients, security and version support, and ends in a ranked list of what will fail first and how to fix it. It is not the same as a liveness probe such as redis-cli PING or a Docker HEALTHCHECK, which only tell you whether the server answers.
How long does a Redis health check take?
One to four weeks from kickoff to walkthrough, depending on how complex the estate is, how many instances and topologies are in scope, and how many problems we find along the way. Intake takes a day and the written findings arrive within a week of the review. Sentinel or Cluster estates with several replica sets sit at the longer end, and we confirm the timeline once we know the instance count and focus areas.
Do you need production access?
No. We need visibility, not hands-on access. INFO output, configuration, the slow log, the latency report and replication state can be exported and reviewed. Read-only access speeds things up, and for regulated environments an export plus a working session with your operators is normally enough.
Does it cover Valkey and ElastiCache?
Yes to both. Valkey shares the commands and statistics the checks read. On Amazon ElastiCache or Google Cloud Memorystore we review the settings, clients and symptoms you control; the provider owns node operations, so the findings stay within what you can change.
What does a Redis health check cost?
It is quoted, not list-priced. The drivers are the number of instances or replica sets, whether they are standalone, Sentinel or Cluster, how much history we read, and whether a failover rehearsal is in scope. Send the instance count and your deployment model and we reply to a quote request within 1 hour.
How is this different from monitoring or from AceMQ's Redis support?
Monitoring reports what is happening now. A health check tells you what will happen under conditions you have not hit yet. Support is an SLA over a deployment your team runs, with a 15-minute emergency response. The health check is a standalone engagement and is also the first step when Redis moves onto support or managed services, so the work is not repeated.
Let's talk
Book a Redis Health Check
Tell us how many Redis or Valkey instances you run, whether they are standalone, Sentinel or Cluster, and where they live. We will scope the review and reply to your request within 1 hour.
Get in Touch
Talk to a Redis 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.