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