At a glance
Instance Uptime is how long the Redis process has been running since its last start, read fromINFO server(uptime_in_seconds). A high, steadily climbing number is healthy. A sudden reset to near zero means the instance restarted, which on a cache often means a cold start and a temporary collapse in hit rate while the cache refills.
| What it tracks | uptime_in_seconds from INFO server, rendered in days, hours and minutes. The value counts up while the process lives and resets to zero on every restart or failover to a freshly started node. |
| Data source | INFO server, uptime_in_seconds (and uptime_in_days). |
| Time window | RT (real-time, read on each refresh). |
| Alert trigger | None by default. A reset is the signal to watch; pair with the hit-rate and memory cards to gauge cold-start impact. |
| Roles | owner, engineering, operations |
What it tracks
Uptime is the time elapsed since the Redis process started, not the time since the host booted. It resets on a planned restart, a crash, an out-of-memory kill, or a managed-service maintenance event. On a pure cache an unexpected reset matters because the keyspace is rebuilt from cold: Keyspace Hit Rate % will sag while the cache warms, pushing more load onto the origin database behind it. On a persistence-backed instance the dataset reloads from RDB or AOF, so the keyspace returns quickly but there is still a brief unavailability window. Read uptime alongside Last RDB Save (minutes ago) and Connected Replicas so a restart can be tied to whether failover and recovery behaved as designed.Reconciling against the source
Runredis-cli INFO server and read uptime_in_seconds (or uptime_in_days for the rounded figure). On Amazon ElastiCache, correlate against the EngineUptime CloudWatch metric and the cluster events log. A reset in either source confirms a restart rather than a sampling gap.