Skip to main content

A tour of the console

These are the console's own screens. They are the UI's screenshot test baselines, rendered at 1440 px from the API's fixtures: two Clusters in team-a, orders healthy and billing failing over. The images follow the site's light or dark theme. The site build copies them from the UI's baselines (docs/site/scripts/copy-screens.mjs, run by npm run build) instead of keeping its own copies, and fails on a missing one, so what you see here is what the console draws today.

Every screen says where each fact comes from (an operator claim, an instance's self-report, Kubernetes, or the console's own inference), how old it is, and what the console cannot see from where it stands. A verdict is never shown by colour alone: it has a word and a glyph, and "stale" when its source is.

Clusters​

The Clusters list: team-a/billing marked critical and stale while failing over from billing-1 to billing-2, with 1 of 2 instances and no completed backup; team-a/orders marked ok with 3 of 3 instances and a backup 5 hours ago. A banner says the console may not list Clusters in team-a-staging.The Clusters list: team-a/billing marked critical and stale while failing over from billing-1 to billing-2, with 1 of 2 instances and no completed backup; team-a/orders marked ok with 3 of 3 instances and a backup 5 hours ago. A banner says the console may not list Clusters in team-a-staging.

The first screen lists the Clusters you may see in the namespaces the console watches, one row each: verdict, phase, primary, ready instances, last backup and the count of diagnostics findings by severity. The last backup is the newest completed Backup's stop time; a stop time a plugin left unset (1970) or set in the future is not one, and such a backup is then timed by CloudNativePG's completion stamp (status.reconciliationTerminatedAt, seconds after the backup ended).

A backup whose times are more than five minutes before the operator started it has neither: the instance's clock and the operator's disagree (the instance runs behind or the operator ahead, and the console cannot tell which). It is timed by the earlier of its creation and the operator's start stamp. Both come before the backup started running, so a long backup shows older than it is, never fresher. The list and the Overview's backups panel show that time unmarked. Only the backup line of the cluster Overview's health roll-up says it is the completion stamp, or that the stop time and completion stamp are not plausible because the clocks disagree; the Backups screen shows no times for such a backup and does not mark it.

A failed Backup is timed by the latest of when CloudNativePG marked it failed, when the operator started it and its creation. A backup that waited behind a successful one and failed after it still shows as a failure after the last completed backup, also when its instance's failure stamp is dropped because the clocks disagree. A namespace the console cannot read is named in a banner rather than shown as empty. Tick two rows to compare them. What you may see is decided by the API server for your own identity (authorization).

Overview​

The overview of the Cluster orders: an overall health panel with each contributor (phase, Ready condition, instances ready, WAL archiving, last backup, diagnostics) marked ok with its source; a wiring diagram of poolers, services, instances, the backup schedule, volumes and the object store; primary, backups and WAL archiving panels; a failover verdict naming orders-2; instance cards; conditions; sources; and the list of operations you are allowed.The overview of the Cluster orders: an overall health panel with each contributor (phase, Ready condition, instances ready, WAL archiving, last backup, diagnostics) marked ok with its source; a wiring diagram of poolers, services, instances, the backup schedule, volumes and the object store; primary, backups and WAL archiving panels; a failover verdict naming orders-2; instance cards; conditions; sources; and the list of operations you are allowed.

The roll-up verdict and each fact it rests on, with its source and age. Below it: the Cluster's wiring, the primary election, backups and WAL archiving, "if the primary failed now", the instance cards, conditions and recent warnings. When the phase is not healthy, the overview also explains why the operator is waiting. The last panels list the sources the page rests on and what you may do here.

The CloudNativePG version in the header comes from one detector, which the diagnostics use as well. It tries these sources in order: the instanceManagerVersion the instances report, the operator's cnpg.io/operatorVersion annotation on the instance Pods, the bootstrap-controller image tag, the commit hash in the Cluster status, and last the feature floors. The operator rewrites the annotation as soon as it is upgraded, but the instance managers change only when they are replaced. While the two disagree, the header says "CNPG upgrade in progress" and names both versions.

Instances​

The Instances table of the Cluster billing: billing-1 critical and stale, primary, not ready in CrashLoopBackOff, its status port not reachable; billing-2 unknown and stale, its status port not verifiable because the Cluster's CA is not in the console's bundle; billing-3 warning, its status port without TLS.The Instances table of the Cluster billing: billing-1 critical and stale, primary, not ready in CrashLoopBackOff, its status port not reachable; billing-2 unknown and stale, its status port not verifiable because the Cluster's CA is not in the console's bundle; billing-3 warning, its status port without TLS.

Each instance as the operator, the Pod and the instance's own /pg/status see it, side by side, so a disagreement between them is visible. When the console cannot read an instance's status, the row says why and what fixes it (for example the instance CA bundle). A fenced or restarting instance whose manager answered without reaching PostgreSQL reads "PostgreSQL not read", with the error it hit: its PostgreSQL fields are unread, never zero.

Replication​

The Replication screen of orders: the primary and the declared synchronous replication; the synchronous set PostgreSQL applied (ANY 1 of orders-2 and orders-3); a failover verdict saying orders-2 would be promoted with no acknowledged commit lost, with the election ranking; WAL senders, WAL receivers and replication slots, including a logical slot debezium marked warning.The Replication screen of orders: the primary and the declared synchronous replication; the synchronous set PostgreSQL applied (ANY 1 of orders-2 and orders-3); a failover verdict saying orders-2 would be promoted with no acknowledged commit lost, with the election ranking; WAL senders, WAL receivers and replication slots, including a logical slot debezium marked warning.

The declared synchronous configuration next to the set PostgreSQL applied, then the failover rehearsal: which replica the operator would promote if the primary failed now, and whether an acknowledged commit could be lost. Below: WAL senders with their lag, WAL receivers, and replication slots, where an inactive slot holding WAL stands out.

Backups and restore drills​

The Backups screen of orders: backup and WAL archiving status through a CNPG-I plugin; the repository cross-check from the evidence agent with a coverage gap warning; a recovery window bar over 7 days with a red segment where WAL is missing; a form to check a restore target; the restore drill panel with one passed and one failed drill; the Backup objects and the schedule.The Backups screen of orders: backup and WAL archiving status through a CNPG-I plugin; the repository cross-check from the evidence agent with a coverage gap warning; a recovery window bar over 7 days with a red segment where WAL is missing; a form to check a restore target; the restore drill panel with one passed and one failed drill; the Backup objects and the schedule.

The operator's Backup objects, the plugin's view and the repository evidence, side by side. The recovery window bar shows the span a restore can target, holes included, and answers "can I restore to this time?". Restore drills restore the latest backup into a throwaway Cluster and report what they checked and what they did not.

A Backup names its Cluster only by spec.cluster.name, so a Cluster deleted and recreated under the same name still finds the old ones. A Backup created before the Cluster, or owned by a Cluster with another UID, is listed and marked "predates this Cluster", and it counts in none of this Cluster's last backup, wiring diagram or recovery bar.

"Last backup" turns to warning when it is overdue: older than twice the period of the most frequent active ScheduledBackup (the operator's own lastScheduleTime to nextScheduleTime), or, when no period is known, older than 7 days. The panel then says "no backup cadence known", so one old backup is never ok forever.

Storage​

The Storage screen of orders: the volumes the Cluster declares (PG_DATA 40Gi, PG_WAL 5Gi on fast-ssd); the persistent volume claims of each instance, orders-3 data volume shown in progress while being resized from 20Gi to 40Gi; and a volume forecasts panel explaining that no instance reports its volume usage.The Storage screen of orders: the volumes the Cluster declares (PG_DATA 40Gi, PG_WAL 5Gi on fast-ssd); the persistent volume claims of each instance, orders-3 data volume shown in progress while being resized from 20Gi to 40Gi; and a volume forecasts panel explaining that no instance reports its volume usage.

The volumes the Cluster declares, each PVC with its phase, capacity and resize state, and the usage an instance reports. When usage is reported, the console forecasts when each volume fills; otherwise it says which source is missing.

Diagnostics​

The Diagnostics screen of billing, Incidents tab: a critical incident, instance billing-1 restarting in a loop, with the verbatim CrashLoopBackOff evidence, a kubectl logs command to check it yourself, and the related warning that the operator is failing over; and a note that no restore drill has passed in the last 90 days.The Diagnostics screen of billing, Incidents tab: a critical incident, instance billing-1 restarting in a loop, with the verbatim CrashLoopBackOff evidence, a kubectl logs command to check it yourself, and the related warning that the operator is failing over; and a note that no restore drill has passed in the last 90 days.

The diagnostics run for the Cluster, grouped into incidents: each finding with its severity, its verbatim evidence and a command to check it yourself. The Checks tab lists every check and its outcome, including those that could not run; Triage starts from a symptom.

Events​

The Events screen of billing: a live event watch over one hour, listing a FailingOver event on Cluster/billing from the operator and a Pulled event on Pod/billing-1 from the kubelet, with counts and origins.The Events screen of billing: a live event watch over one hour, listing a FailingOver event on Cluster/billing from the operator and a Pulled event on Pod/billing-1 from the kubelet, with counts and origins.

Kubernetes Events about the Cluster and its children, bounded by age and count, each with its origin (the operator or the kubelet).

History: timeline and revisions​

The incident timeline of billing over 24 hours: a critical finding 'no ready primary for 90 s', the phase change to Failing over, the failover from billing-1 to billing-2, readiness probe failures, an OOMKilled container restart, a failed backup, a spec change, the console starting with the gap it did not observe, and a cleared WAL archiving finding. Filters by kind sit above.The incident timeline of billing over 24 hours: a critical finding 'no ready primary for 90 s', the phase change to Failing over, the failover from billing-1 to billing-2, readiness probe failures, an OOMKilled container restart, a failed backup, a spec change, the console starting with the gap it did not observe, and a cleared WAL archiving finding. Filters by kind sit above.

The incident timeline puts phase changes, failovers, restarts, backups, findings, revisions and Events on one time axis, and marks when each time comes from the console's clock or from the source's. Times when the console was not watching are shown as gaps, not as quiet.

Revision 42 of Cluster/orders: the changed fields (instances 2 to 3, max_connections 200 to 300, work_mem 4MB to 16MB) with their field manager, a line-by-line diff, and 'what this change sets in motion': a restart, replicas first then a switchover of the primary, with max_connections needing a restart and work_mem a reload.Revision 42 of Cluster/orders: the changed fields (instances 2 to 3, max_connections 200 to 300, work_mem 4MB to 16MB) with their field manager, a line-by-line diff, and 'what this change sets in motion': a restart, replicas first then a switchover of the primary, with max_connections needing a restart and work_mem a reload.

A revision shows what changed in the definition, who declared the change, and the change preview: which parameters reload, which restart, and in what order the operator rolls the instances.

Metrics​

The Metrics screen of orders: the latest backend count of each instance, orders-3 not reported because its exporter did not answer, and a short chart of replication lag for orders-2 and orders-3 over the last minute.The Metrics screen of orders: the latest backend count of each instance, orders-3 not reported because its exporter did not answer, and a short chart of replication lag for orders-2 and orders-3 over the last minute.

The latest exporter readings as tiles and a short series the console keeps (one hour by default), or charts from Prometheus when it is configured. The console is not a monitoring system; this screen links to yours.

Insight​

The Blocking insight screen of orders: on the primary orders-1, pid 4711 from billing-api idle in transaction for 37 minutes blocks pid 5120 (flyway), which blocks pid 5133 (orders-api); the replicas have no backend waiting on a lock. A pgAdmin panel says the console ends no backend.The Blocking insight screen of orders: on the primary orders-1, pid 4711 from billing-api idle in transaction for 37 minutes blocks pid 5120 (flyway), which blocks pid 5133 (orders-api); the replicas have no backend waiting on a lock. A pgAdmin panel says the console ends no backend.

With the insight pack enabled, a Cluster's Insight section shows what a DBA usually checks with SQL: wraparound and vacuum, blocking (the lock graph, root blockers first, above), the costliest statements, index hygiene and connections. The console runs no SQL: the numbers come from the instances' exporters.

The team-wide Query insight page: one statement regressed 3.25 times against the same hour a day earlier, the top statements across Clusters by total time, and the coverage of each Cluster (insight pack enabled on orders, not on billing).The team-wide Query insight page: one statement regressed 3.25 times against the same hour a day earlier, the top statements across Clusters by total time, and the coverage of each Cluster (insight pack enabled on orders, not on billing).

The team-wide query insight page lists regressions and the costliest statements of every Cluster you may see, and says which Clusters it covers.

Operations​

The Operations screen of orders: request an on-demand backup, reload configuration, restart the cluster, promote a replica, and run a restore drill (refused for this user by the API server), each with the permission it needs; and a recent backup operation shown as operator acting.The Operations screen of orders: request an on-demand backup, reload configuration, restart the cluster, promote a replica, and run a restore drill (refused for this user by the API server), each with the permission it needs; and a recent backup operation shown as operator acting.

What the console may do: backup, reload, restart, promote and restore drill, each with the permission it needs and its consequences. You type the target's name to confirm; the request is sent as you, and then followed until the operator reports an outcome.

Access requests​

The Access requests page: a form to ask for the View or Operate capability in a namespace with a justification and an optional expiry; my requests, one waiting for review and one approved; and requests to review, with approve and deny buttons, one approved grant whose RoleBinding is missing, one denied and one expired.The Access requests page: a form to ask for the View or Operate capability in a namespace with a justification and an optional expiry; my requests, one waiting for review and one approved; and requests to review, with approve and deny buttons, one approved grant whose RoleBinding is missing, one denied and one expired.

Access requests: ask for view or operate rights in a namespace, follow your requests, and decide those of others when you may create the RoleBinding. Nobody decides a request that names them.

Daily digest​

A daily digest covering 24 hours: marked partial because the console was down during the window; totals of Clusters, findings, failovers, failed backups and restarts; the console's own gaps; then per Cluster, billing critical with its failover, restart, failed backup and findings, and orders ok with nothing happening.A daily digest covering 24 hours: marked partial because the console was down during the window; totals of Clusters, findings, failovers, failed backups and restarts; the console's own gaps; then per Cluster, billing critical with its failover, restart, failed backup and findings, and orders ok with nothing happening.

The daily digest sums up the last 24 hours per Cluster. It says when it is partial: a window the console did not fully observe is not an all-clear.

Administration​

The Administration page: per watched namespace, the PgAdmin and EvidenceAgent objects with their health, a namespace the user may not list; this console's version, watched namespaces and the state of its internal loops; and the daily digest delivery per channel, with a mail channel retrying because the server does not offer STARTTLS.The Administration page: per watched namespace, the PgAdmin and EvidenceAgent objects with their health, a namespace the user may not list; this console's version, watched namespaces and the state of its internal loops; and the daily digest delivery per channel, with a mail channel retrying because the server does not offer STARTTLS.

The PgAdmin and EvidenceAgent objects you may list, the console's own health, and the delivery state of the daily digest.