Redis Sentinel metrics reference

This page expands on the Redis Sentinel alert thresholds in Exporters with a per-metric description, the conditions that should trigger an alert, and how to troubleshoot each one.

Redis Sentinel is the high-availability layer that watches the Redis data instances and automatically promotes a replica to primary if the primary becomes unavailable. A Redis deployment can look completely healthy on the data instance metrics in Redis metrics reference while Sentinel’s ability to fail over is silently broken, so Sentinel needs its own monitoring, separate from the data instances it protects.

Active Sentinels

Metric: count(redis_up{job="redis_sentinel"} == 1)

This counts how many Sentinel instances are currently operational and responding to health checks. Sentinel needs a quorum of healthy instances to make a failover decision. When too many are unavailable, the cluster loses the ability to fail over automatically, even during a legitimate primary failure.

Monitored primaries

Metric: redis_sentinel_masters{job="redis_sentinel"}

The number of Redis primary instances the Sentinel cluster is tracking. This value should stay constant and match your configured topology. A change suggests configuration drift or a split-brain condition where different Sentinels are tracking different primaries.

TILT mode status

Metric: redis_sentinel_tilt{job="redis_sentinel"}

TILT mode is Sentinel’s self-protection mechanism. It activates when Sentinel detects system instability, such as a Network Time Protocol (NTP) time jump, CPU starvation, or a scheduling delay. While in TILT (30 seconds by default), Sentinel stops making failover decisions, stops marking instances as down, and stops voting on quorum, although it keeps monitoring instance health.

Running scripts

Metric: redis_sentinel_running_scripts{job="redis_sentinel"}

The number of notification or client-reconfiguration scripts currently executing in response to a Sentinel event, such as a failure being detected or a failover starting or completing.

Primary status

Metric: redis_sentinel_master_status{job="redis_sentinel", master_status="ok"}

Reports 1 when the primary is responding normally from Sentinel’s perspective and 0 when Sentinel has marked it down. This is the first trigger in the failover chain: once quorum agrees the primary is down, Sentinel promotes a replica.

Current primary address

Metric: redis_sentinel_master_status{job="redis_sentinel"} (master_address label)

The host and port currently serving as primary. Tracking this address confirms a failover completed successfully and that application connection strings point to the right instance.

Quorum check status

Metric: redis_sentinel_master_ckquorum_status{job="redis_sentinel"}

A continuous, proactive check of whether the Sentinel cluster could currently achieve quorum, independent of whether the primary happens to be healthy right now. This tells you whether Sentinel could fail over if it needed to.

Sentinel health: total vs. healthy

Metrics:

• redis_sentinel_master_sentinels{job="redis_sentinel"} (total configured)
• redis_sentinel_master_ok_sentinels{job="redis_sentinel"} (currently healthy)

The gap between these two values indicates a Sentinel availability problem, and tracking it historically helps correlate a Sentinel outage with maintenance windows or infrastructure incidents elsewhere.

Replica health: total vs. healthy

Metrics:

• redis_sentinel_master_slaves{job="redis_sentinel"} (total configured)
• redis_sentinel_master_ok_slaves{job="redis_sentinel"} (currently healthy)

The gap represents lost data redundancy and fewer, or zero, candidates available for promotion if the primary fails.

Sentinel instance details

Metric: redis_instance_info{job="redis_sentinel"}

Metadata for each Sentinel instance, including hostname, Redis version, operating system, process ID, and TCP port. Use it to confirm consistent configuration across all Sentinels, especially after an update.

Down-after-milliseconds

Metric: redis_sentinel_master_setting_down_after_milliseconds{job="redis_sentinel"}

How long Sentinel waits without a valid response before marking an instance subjectively down (SDOWN). This directly affects failover latency: too low causes false positives from transient network blips, too high delays detection of a real failure. The default is 5000 ms.

Failover timeout

Metric: redis_sentinel_master_setting_failover_timeout{job="redis_sentinel"}

The maximum time allowed for a complete failover, covering replica promotion, reconfiguring other replicas, and verifying the new primary. The default is 60000 ms.

Parallel syncs

Metric: redis_sentinel_master_setting_parallel_syncs{job="redis_sentinel"}

How many replicas can resynchronize from a new primary simultaneously during failover or recovery. Too high can overwhelm the primary during failover; too low extends the time to restore full redundancy. The default is 1.

ACL denied commands rate

Metric: rate(redis_acl_access_denied_cmd_total{job="redis_sentinel"}[5m])

The rate of commands rejected due to access control list (ACL) violations, indicating the monitoring account lacks permissions needed for full Sentinel metrics collection. This should be zero.

Authentication failures rate

Metric: rate(redis_acl_access_denied_auth_total{job="redis_sentinel"}[5m])

The rate of failed authentication attempts against a Sentinel instance.

Network I/O throughput

Metrics:

• rate(redis_net_input_bytes_total{job="redis_sentinel"}[5m])
• rate(redis_net_output_bytes_total{job="redis_sentinel"}[5m])

Sentinel network usage is normally modest and consistent, so both a sudden drop and a sudden spike are meaningful signals.

Commands processed rate

Metric: rate(redis_commands_processed_total{job="redis_sentinel"}[5m])

The rate of commands a Sentinel instance is processing per second, covering health checks, Sentinel protocol traffic, and client queries. A drop toward zero suggests Sentinel has stopped monitoring.