At a glance
Total Keys (db0) is the number of keys currently held in logical database 0, read straight fromINFO keyspace(thedb0:keys=field). It is the simplest possible measure of how much your Redis instance is holding. Watch the trend, not the absolute number: a flat or gently rising key count is normal, while a sudden cliff usually means a flush, an eviction storm, or a mass-expiry event.
| What it tracks | The keys= value parsed from the db0: line returned by INFO keyspace. Most ecommerce Redis deployments keep everything in db0, so this is the working key population for caches, sessions, rate-limit counters, and queues. |
| Data source | INFO keyspace, db0:keys=. The same line also reports expires= (keys with a TTL) and avg_ttl. |
| Time window | RT (real-time, read on each refresh). |
| Alert trigger | None by default. This is a context metric; pair it with eviction and memory cards for alerting. |
| Roles | engineering, operations |
What it tracks
Redis groups keys into numbered logical databases (0 to 15 by default). The overwhelming majority of production workloads, and every managed offering that disablesSELECT such as Amazon ElastiCache cluster mode and Redis Cluster, keep all data in db0. This card reports the live keys= count for that database, parsed from INFO keyspace. A steadily growing count with no matching TTL coverage is the classic signature of an unbounded cache that will eventually hit maxmemory and start evicting. A flat count that suddenly drops to near zero almost always means a FLUSHDB, a failover to a cold replica, or a mass expiry. Read it next to Evicted Keys / minute and Memory Used vs Maxmemory % to tell growth from pressure.
Reconciling against the source
Runredis-cli INFO keyspace and read the db0:keys= field, or run redis-cli DBSIZE for the same count without the surrounding stats. On Amazon ElastiCache the equivalent is the CurrItems CloudWatch metric. Small differences between our reading and a manual check are expected because keys expire continuously between samples.