At a glance
The count of physical streaming standbys currently connected to the primary and actively receiving WAL. This is the headcount of your high-availability and read-scaling fleet: it answers “how many standbys are attached right now?” If the number you designed for is two and the card reads one, a standby has dropped out and your redundancy has quietly halved, often long before anyone notices the missing capacity.
What it tracks
The card reports Active Streaming Replicas for the selected period, refreshed in real time (RT). It counts the rows in pg_stat_replication on the primary whose state is a live streaming value (streaming, catchup, or backup), one row per connected standby. A standby that has disconnected drops out of the view and the count falls. Read this number against your intended topology: a stable count that matches your design is healthy; a drop is the signal that a replica has fallen off, which removes both a read-scaling node and a failover candidate. Because the count says nothing about freshness, always pair it with Replication Lag (seconds) and WAL Lag Bytes (primary to standby): a standby can be connected (counted here) yet badly behind. Failover Readiness then tells you whether any of the counted standbys is actually safe to promote. On managed services the count is reconciled with the provider’s read-replica inventory (RDS read replicas, Aurora reader instances, Cloud SQL replicas).
Reconciling against the source
Confirm the count natively withSELECT count(*) FROM pg_stat_replication; on the primary, or list the standbys with SELECT application_name, state, sync_state FROM pg_stat_replication;. On managed services compare against the provider’s own inventory: the read-replica list in the RDS console, Aurora reader instances in the cluster, or the replica list in Cloud SQL. A native count higher than the card usually means a standby is connected but in a non-streaming state; a count lower means a replica has disconnected since the last refresh.