Redis can keep responding while memory pressure quietly approaches a hard limit. A scheduled web cron job can collect the right memory counters, compare them with safe thresholds, and alert before eviction, latency spikes, or an out-of-memory error affects your application.
This guide builds a practical Redis memory monitor around a protected web endpoint. It focuses on capacity, fragmentation, eviction behavior, and growth rate rather than treating a successful connection as proof that the cache is healthy.
Why Redis needs memory-specific monitoring
Redis stores its working data in memory, so capacity problems behave differently from ordinary disk shortages. A node may answer health checks with low latency while the remaining headroom shrinks. When the configured limit is reached, behavior depends on the eviction policy: Redis may remove keys, reject writes, or keep growing until the host is under pressure.
A useful monitor distinguishes allocated data, process overhead, fragmentation, configured limits, and recent eviction activity. This complements server disk-space monitoring; neither signal replaces the other.
Collect the essential Redis metrics
Use a server-side script to query Redis over its private network and expose only a protected summary endpoint to the web cron service. Start with these fields from Redis statistics:
used_memoryandused_memory_rssfor logical and resident memory.maxmemoryfor the configured data limit.mem_fragmentation_ratiofor allocator and operating-system overhead.evicted_keysandexpired_keysto separate pressure from normal expiry.keyspace_hitsandkeyspace_missesto track cache usefulness.connected_clientsandblocked_clientsfor workload context.
Record a timestamp and Redis instance identifier with every sample. If you operate multiple nodes, collect each node independently; an average can hide one replica or shard approaching its limit.
Calculate memory headroom
When maxmemory is configured, calculate both usage and remaining capacity:
usage_percent = (used_memory / maxmemory) * 100
headroom_bytes = maxmemory - used_memoryA percentage is easy to alert on, while absolute headroom tells you whether a workload burst can fit. If maxmemory is zero, compare resident memory with a documented host budget rather than pretending capacity is unlimited.
Watch trends, not only thresholds
A node at 70 percent usage may be stable for weeks or may be growing fast enough to fail tonight. Store recent samples and calculate bytes added per hour. Estimate time to the warning threshold from the current growth rate, but suppress the estimate when usage is flat or falling.
Trend monitoring is especially useful after releases, imports, or cache-key changes. Pair it with data pipeline freshness monitoring when ingestion jobs populate Redis on a schedule.
Interpret fragmentation carefully
Resident memory can exceed logical Redis memory because of allocator behavior, deleted keys, and operating-system pages. A high fragmentation ratio deserves investigation, but a ratio alone is not an incident. Small datasets often produce misleading ratios, so also compare the absolute gap between used_memory_rss and used_memory.
Alert when both the ratio and the absolute overhead are material for your instance size. Record whether active defragmentation is enabled, but do not make the monitoring endpoint change server configuration automatically.
Detect eviction before it becomes invisible
The cumulative evicted_keys counter matters only when compared with the previous sample. Calculate the delta per interval. Any unexpected increase means Redis removed data because of memory pressure under an eviction policy. A rising cache-miss rate at the same time can turn a quiet capacity issue into database load.
If eviction is expected for this cache, alert on sustained rate or on a miss-rate increase instead of every single key. If Redis contains queues, sessions, or other data that must not be evicted, treat the first eviction as critical. Queue operators should also use background queue backlog monitoring for an independent workload signal.
Know the configured eviction policy
Include the active maxmemory-policy in the monitor response or deployment inventory. Policies such as least-recently-used removal, time-to-live-based removal, and no-eviction produce very different failure modes. The alert should state what the node will do at the limit so the responder knows whether to expect missing cache entries or rejected writes.
Build a safe monitoring endpoint
Do not expose Redis itself to the public internet. The web-accessible script should run near Redis, authenticate locally, apply a short timeout, and return only the minimum operational summary. Protect it with an unguessable secret or request authentication using the approach in How to Secure Web Cron Endpoints.
Return a clear status, a compact JSON summary, and an appropriate HTTP response. Avoid including credentials, full keys, values, customer identifiers, or raw configuration in the response or logs.
Choose useful alert levels
A starting policy might warn at 75 percent usage, escalate at 85 percent, and become critical at 95 percent or after unexpected eviction. Adjust those numbers for peak bursts, failover requirements, persistence overhead, and the time your team needs to add capacity.
Include usage, headroom, growth rate, fragmentation overhead, eviction delta, instance name, and a runbook link in every alert. Deduplicate repeated notifications and send a recovery event when the node returns to a safe state. A daily summary can use the pattern from scheduled email reports.
Schedule and lock the check
For most caches, a one- to five-minute interval is sufficient. Very small or slow-changing instances may need less frequent checks. The script should finish quickly and release its Redis connection even when parsing fails.
Prevent simultaneous executions so slow network calls do not create overlapping monitors. The locking techniques in How to Prevent Overlapping Cron Jobs apply directly.
Test failure conditions
Use a staging instance or recorded metric fixtures to test missing limits, high fragmentation, eviction deltas, authentication failure, timeouts, failover, and malformed responses. Confirm that one unavailable node does not erase the results for other nodes and that recovery notifications work.
Operational checklist
- Query Redis privately and expose only a protected summary endpoint.
- Measure logical memory, resident memory, the configured limit, and headroom.
- Track growth rate and estimated time to a warning threshold.
- Compare eviction and cache-miss counters between samples.
- Include the active eviction policy in alerts and runbooks.
- Set thresholds from real bursts and failover requirements.
- Lock the job, deduplicate alerts, and test recovery.
A Redis memory monitor is most valuable before the limit is reached. Combine capacity, trend, fragmentation, and eviction signals in one short scheduled check, and your team can respond while Redis is still fast and predictable.