> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.itential.com/itential-platform/6/monitor/metrics-reference/redis-sentinel/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server.

# Redis Sentinel metrics reference

> Detailed reference for every Redis Sentinel metric collected by redis_exporter, including alert thresholds and troubleshooting guidance.

This page expands on the [Redis Sentinel alert thresholds](/itential-platform/monitor/exporters#redis_exporter-sentinel) in [Exporters](/itential-platform/monitor/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](/itential-platform/monitor/metrics-reference/redis) 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.

| Threshold | Condition                                                        |
| --------- | ---------------------------------------------------------------- |
| Warning   | Active Sentinels \< 3 (one unavailable, reduced redundancy)      |
| Critical  | Active Sentinels \< 2 (quorum lost, automatic failover disabled) |

## 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.

| Threshold | Condition                                              |
| --------- | ------------------------------------------------------ |
| Critical  | Monitored primaries != expected value                  |
| Critical  | Value differs between Sentinel instances (split-brain) |

## 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.

TILT is a subtle failure. Sentinel keeps responding to queries and the data instances keep serving traffic, but the cluster has effectively lost its self-healing capability. If multiple Sentinels enter TILT at the same time as an actual primary failure, the cluster loses automatic failover entirely.

| Threshold | Condition                                                        |
| --------- | ---------------------------------------------------------------- |
| Critical  | TILT mode active (value > 0) on any Sentinel                     |
| Warning   | TILT mode activations > 1/hour (persistent infrastructure issue) |

## 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.

| Threshold | Condition                                                  |
| --------- | ---------------------------------------------------------- |
| Warning   | Running scripts > 5 (possible event storm)                 |
| Critical  | A script running for > 5 minutes (hung script; check logs) |

## 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.

| Threshold | Condition                                                   |
| --------- | ----------------------------------------------------------- |
| Critical  | Primary status == 0                                         |
| Critical  | Primary status == 0 for > 2 minutes (failover may be stuck) |

## 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.

| Threshold    | Condition                                                              |
| ------------ | ---------------------------------------------------------------------- |
| Notification | Primary address changes (failover occurred)                            |
| Critical     | Primary address doesn't match documented topology                      |
| Warning      | Primary address differs between Sentinel instances (inconsistent view) |

## 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.

| Threshold | Condition                                                                   |
| --------- | --------------------------------------------------------------------------- |
| Critical  | Quorum check status == 0 (cannot achieve quorum)                            |
| Warning   | Quorum is marginal (exactly at threshold, no tolerance for another failure) |

## 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.

| Threshold | Condition                                                                    |
| --------- | ---------------------------------------------------------------------------- |
| Warning   | (Total − OK) >= 1 for > 2 minutes                                            |
| Critical  | OK Sentinels \< quorum requirement                                           |
| Critical  | OK Sentinels differs between Sentinel instances (inconsistent cluster state) |

## 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.

| Threshold | Condition                                                            |
| --------- | -------------------------------------------------------------------- |
| Warning   | OK replicas \< total for > 2 minutes                                 |
| Critical  | OK replicas == 0 for > 1 minute (no redundancy, failover impossible) |
| Warning   | OK replicas \< total / 2 for > 5 minutes (majority unhealthy)        |

## 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.

| Threshold    | Condition                                                            |
| ------------ | -------------------------------------------------------------------- |
| Warning      | Redis version differs between Sentinel instances                     |
| Critical     | `redis_mode != "sentinel"` for an instance expected to be a Sentinel |
| Notification | Redis version changes (deployment or update occurred)                |

## 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.

| Threshold    | Condition                                             |
| ------------ | ----------------------------------------------------- |
| Warning      | Value \< 3000 ms (false triggers from network jitter) |
| Warning      | Value > 30000 ms (excessive detection delay)          |
| Notification | Value changes unexpectedly (configuration drift)      |

## 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.

| Threshold    | Condition                                                                   |
| ------------ | --------------------------------------------------------------------------- |
| Warning      | Value \< 30000 ms (insufficient for large clusters or high replication lag) |
| Warning      | Value differs between Sentinel instances                                    |
| Notification | Value changes unexpectedly                                                  |

## 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.

| Threshold    | Condition                                         |
| ------------ | ------------------------------------------------- |
| Warning      | Value > 3 (may overwhelm primary during failover) |
| Warning      | Value > total replica count (misconfiguration)    |
| Notification | Value differs between Sentinel instances          |

## 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.

| Threshold | Condition                                                              |
| --------- | ---------------------------------------------------------------------- |
| Warning   | Any denied commands detected                                           |
| Critical  | Rate > 1/sec for > 5 minutes                                           |
| Critical  | Rate > 100/sec (severe misconfiguration, monitoring effectively blind) |

## 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.

| Threshold | Condition                                                                  |
| --------- | -------------------------------------------------------------------------- |
| Warning   | Rate > 0.1/sec for > 5 minutes                                             |
| Critical  | Rate > 10/sec (possible brute force or severe misconfiguration)            |
| Critical  | Rate > 100/sec (active security incident or authentication system failure) |

## 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.

| Threshold | Condition                                                                                      |
| --------- | ---------------------------------------------------------------------------------------------- |
| Warning   | Throughput drops to near zero unexpectedly (connectivity loss or all monitored instances down) |
| Warning   | Throughput increases 10x baseline for > 10 minutes                                             |
| Critical  | Throughput exceeds interface capacity for > 5 minutes                                          |

## 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.

| Threshold | Condition                                                                |
| --------- | ------------------------------------------------------------------------ |
| Warning   | Rate \< 10/sec for > 5 minutes (Sentinel may not be actively monitoring) |
| Critical  | Rate \< 1/sec for > 2 minutes (Sentinel appears non-functional)          |
| Warning   | Rate > 1000/sec for > 5 minutes (unusual activity)                       |
| Critical  | Rate > 5000/sec (resource exhaustion risk)                               |

> Detailed reference for every Redis Sentinel metric collected by redis_exporter, including alert thresholds and troubleshooting guidance.