> This page is for Itential Platform On-Prem, version 2023.2.
> For other versions, use one of these documentation indexes:
> - 6 (default): https://docs-test.itntl.com/itential-platform/6/llms.txt
> - 2023.2: https://docs-test.itntl.com/itential-platform/2023-2/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs-test.itntl.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs-test.itntl.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.

> **Warning**
>
> 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)                               |