Open the database → Metrics tab in my.cubepath.com.
What's charted
| Chart | Unit | What it tells you |
|---|---|---|
| Connections | count | How many clients are connected. A flat line at your pool's maximum means clients are queueing, not that the database is idle |
| CPU usage | cores | Sustained high CPU usually means missing indexes or an expensive query, not an undersized plan |
| Memory | GiB | Working set size. When it plateaus at the plan limit, cache hit rates fall and query latency climbs |
| Replication lag | seconds | How far behind the replicas are |
Replication lag is the one to watch
Lag is the metric that quietly breaks correctness rather than availability. If your application reads from replicas, lag is the window in which a read can return data from before a write your user just made — the classic "I saved it but it's not there" bug.
- A few seconds during a heavy write burst is normal.
- Lag that keeps growing means the replica can't keep up. That's a bigger write volume than the plan can replicate, or a long-running query on the replica blocking apply.
- Lag that never returns to near zero puts your failover at risk: promoting a replica that's minutes behind loses those minutes of writes.
Time range and live mode
Pick last hour, 6 hours, 24 hours, 3 days or 7 days, and turn on Live for a continuously refreshing view while you test a change.
NoteMetric collection starts shortly after provisioning finishes, so charts can stay empty for a few minutes on a brand-new cluster. If a single series has no data yet, the chart says so rather than showing a misleading zero.
TipRead connections and CPU together. High CPU with few connections is one expensive query; high connections with low CPU is usually a connection pool that's misconfigured or leaking.