Data Systems
    Updated May 2026
    Redis logo

    Redis Monitoring

    Monitor Redis `used_memory`, `mem_fragmentation_ratio`, `keyspace_hits`/`keyspace_misses` ratio, evicted keys, replication offset, and `rejected_connections` in real time — agent-based via the native `INFO` command.

    Start Free TrialView Docs

    Why monitor Redis?

    Redis sits between your app and your database — caching, sessions, rate limiting, queues. When Redis stutters, every request that touches it stutters too, which is most of them. Monitoring catches memory pressure, eviction storms, and slow commands in their first minute, before the cascade hits your DB and your users.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time memory usage and fragmentation metrics
    Track hit/miss ratios and cache effectiveness
    Monitor connected clients and blocked clients
    Eviction rate and keyspace tracking
    Replication lag and slave status monitoring
    Works on both Linux and Windows servers
    1-minute metric collection intervals
    What is Redis monitoring?

    Redis monitoring, explained

    Redis monitoring catches memory pressure, fragmentation, eviction storms, replication drift, and slow commands before they cause OOM kills, dropped connections, or cascading cache misses. Because Redis sits between your app and your DB, a Redis incident is usually a site-wide incident — monitoring it well means catching most cache-layer failures in their first minute. Xitoring auto-discovers your Redis, reads INFO + SLOWLOG + LATENCY on a 1-minute interval, and routes alerts to Slack, PagerDuty, Telegram, or your existing on-call.

    Metrics

    What we monitor

    Used Memory

    Total memory allocated by Redis including overhead.

    Memory Fragmentation Ratio

    Ratio of OS-allocated memory to Redis-allocated memory. Values above 1.5 indicate fragmentation.

    Connected Clients

    Number of currently connected client connections.

    Blocked Clients

    Number of clients waiting on a blocking call (BLPOP, BRPOP, etc.).

    Keyspace Hit Rate

    Percentage of successful key lookups vs misses, indicating cache effectiveness.

    Evicted Keys

    Number of keys removed due to maxmemory policy.

    Expired Keys

    Number of keys removed due to TTL expiration.

    Commands per Second

    Rate of commands processed by the Redis server.

    Keyspace Size

    Total number of keys stored across all databases.

    Replication Offset

    Replication offset delta between master and replicas.

    RDB Last Save

    Time since last successful RDB snapshot.

    AOF Rewrite

    Status and duration of AOF rewrite operations.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment Redis metrics cross your defined thresholds.

    Redis monitoring trigger configuration dashboard

    Memory Usage

    critical

    Fires when Redis memory consumption exceeds your threshold, risking OOM kills or eviction storms.

    Connected Clients

    warning

    Triggers when client connections exceed the threshold, indicating potential connection leaks.

    Keyspace Hit Rate

    warning

    Alerts when cache hit rate drops below threshold, indicating cache inefficiency or working set changes.

    Evicted Keys

    critical

    Fires when eviction rate spikes, meaning Redis is actively removing data to stay within memory limits.

    Blocked Clients

    warning

    Triggers when clients are blocked waiting on operations, indicating queue congestion.

    Replication Lag

    critical

    Alerts when replica offset falls behind the master, risking data inconsistency in failover scenarios.

    01

    Importance of Redis Monitoring

    Redis serves as the performance backbone for modern applications — handling sessions, caching, rate limiting, and real-time analytics. Without monitoring, memory pressure, eviction storms, and replication drift can silently degrade your entire application stack.

    • Detect memory pressure before OOM kills crash your instance
    • Monitor cache hit rates to ensure optimal application performance
    • Track eviction patterns to right-size your memory allocation
    • Identify connection leaks from application clients
    • Ensure replication consistency for high-availability setups
    Redis monitoring dashboard with memory and hit rate metrics
    Cache performance alerts and eviction monitoring
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade Redis monitoring with zero-config setup. Our lightweight agent auto-discovers your Redis instances, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

    • One-command install — no complex YAML or config files
    • 15+ global monitoring nodes for low-latency checks
    • Unified dashboard for servers, caches, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring Redis cluster monitoring overview
    Alert notification channels configuration
    Use cases

    Common Redis monitoring scenarios

    Where Redis typically runs today — and what could go wrong if no one's watching.

    Speeding up a web app or API

    Redis keeps web apps fast by remembering the results of repeated work. When the cache fills up or stops paying off, every request gets slower and the database underneath gets hammered. We catch the moment the cache stops protecting your app so the team can step in before users feel it.

    High-availability cache split across servers

    Production apps spread Redis across multiple servers so a single failure can't take the cache down. When the copies drift out of sync, the safety net is weaker than it looks. We catch the drift early so failover stays as invisible as it's supposed to be.

    Logins, sessions, and rate-limiting

    When Redis holds user sessions or enforces request limits, hitting its connection ceiling means users suddenly get logged out or blocked from the site. We surface the trend before the ceiling is reached, so it's resolved long before anyone calls support.

    Before you start

    Prerequisites for Redis

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • Redis 5.x or later (Redis 7.x or Redis 8 recommended) running on the host
    • AUTH password if requirepass is set (ACL user with +INFO, +SLOWLOG, +LATENCY perms also supported)
    • Network reachability from Xitogent to the Redis instance (default port 6379)
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your server

    If you haven't already, install the lightweight Xitogent monitoring agent on your server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Ensure Redis INFO command is accessible

    Xitogent uses the Redis INFO command to collect metrics. Make sure your Redis instance allows local connections:

    redis-cli INFO server | head -5
    3

    Enable the Redis integration

    Use the Xitoring dashboard or CLI to enable the Redis integration. Xitogent will auto-detect your Redis instance.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for metrics like memory usage, hit rate, or eviction count to get notified when something needs attention.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status
    Compare

    Considering alternatives?

    See how Xitoring stacks up against the alternatives for Redis monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is Redis monitoring?
    Redis monitoring is the continuous collection of Redis performance data from the native `INFO` command — memory (`used_memory`, `mem_fragmentation_ratio`), keyspace (`keyspace_hits`/`keyspace_misses` for hit ratio, `evicted_keys`, `expired_keys`), connections (`connected_clients`, `blocked_clients`, `rejected_connections`), replication (`master_repl_offset`, per-replica `lag`), persistence (RDB save, AOF rewrite state), plus `SLOWLOG` and `LATENCY HISTORY` for command-level diagnostics — combined with alerting on threshold breaches.
    How do I use the Redis INFO command?
    Connect with `redis-cli` and run `INFO` (or `INFO server`, `INFO memory`, `INFO clients`, `INFO replication`, etc. for a specific section). Each line is `field:value`. Common monitoring fields: `used_memory_human`, `mem_fragmentation_ratio`, `connected_clients`, `instantaneous_ops_per_sec`, `keyspace_hits`/`keyspace_misses`, `evicted_keys`, `rejected_connections`. Xitogent runs `INFO ALL` every minute and trends all of them.
    How do I monitor Redis memory fragmentation?
    `mem_fragmentation_ratio` = `used_memory_rss / used_memory`. A ratio above 1.5 means significant fragmentation (RSS memory is much larger than what Redis actually uses), often after heavy churn or many small allocations. Alert above 1.5. Fix by running `MEMORY PURGE` (Redis 4+) or enabling `activedefrag yes` in `redis.conf`. A ratio below 1.0 means Redis is swapping to disk — that's a much worse problem; restart with more RAM.
    How do I track Redis cache hit ratio?
    Hit ratio = `keyspace_hits / (keyspace_hits + keyspace_misses)` from `INFO stats`. Target 80%+ for caches; below 50% means the cache isn't helping (either TTL too short, working set too large for `maxmemory`, or wrong eviction policy). Alert when hit ratio drops below your baseline. Xitogent trends the ratio over time so you spot regression at the moment it happens.
    How do I detect Redis slow commands?
    Set `slowlog-log-slower-than 10000` (microseconds — anything slower than 10ms gets logged). Read with `SLOWLOG GET 100`. Xitogent surfaces the slowlog count + top offenders so you can find the `KEYS *`, `SMEMBERS huge_set`, or `LRANGE 0 -1` calls freezing your event loop. The single-threaded Redis core means one slow command blocks every other client — slowlog visibility is critical.
    What is rejected_connections in Redis?
    `rejected_connections` from `INFO stats` counts connection attempts dropped because the server hit `maxclients` (default 10000). Any non-zero rate means clients are being turned away — usually app-side connection-pool leaks or sudden traffic spikes. Fix by raising `maxclients` (and OS `ulimit -n` to match) OR fixing the app to reuse connections. Alert on any growth.
    How do I monitor Redis replication?
    On the master, `INFO replication` shows `connected_slaves`, per-slave `lag` (seconds) and `offset` (bytes behind). On replicas, `master_link_status`, `master_link_down_since`, `master_sync_in_progress`, and `slave_repl_offset` show catch-up state. Alert on any replica with lag exceeding your RPO or `master_link_status: down`. For Redis Cluster, also watch per-node `cluster_state` from `CLUSTER INFO`.
    Can I monitor Redis Cluster, Sentinel, KeyDB, and Valkey?
    Yes. Install Xitogent next to each node — Redis Cluster (per shard primary + replicas), Sentinel-managed setups, KeyDB (multi-threaded Redis fork — same RESP wire protocol), and Valkey (Linux Foundation BSD fork backing AWS ElastiCache Serverless and GCP Memorystore). All speak `INFO` and the integration auto-adapts to the variant.
    What Redis versions are supported?
    Redis 5.x through Redis 8 (AGPLv3, 2025) are fully supported, plus Redis Stack and Redis Enterprise. Redis 8 ships RedisJSON, RediSearch, RedisTimeSeries, and RedisBloom in the core distribution — Xitogent detects loaded modules and surfaces their metrics where available. For Valkey or KeyDB users, the same integration works via the shared RESP protocol.

    Start monitoring Redis today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations