Contact UsTry it for free
© 2025 Direct Cursus Technology L.L.C.

PostgreSQL cluster and host status monitoring

Written by
Updated at December 5, 2025

Data on the cluster and host state is available in the management console. You can view them on the Monitoring tab of the cluster management page or in Yandex Monitoring.

Diagnostic information about cluster states is presented as graphs.

Chart update rate:

  • Standard hosts and hosts with an increased RAM to vCPU ratio (memory-optimized): 15 seconds.
  • Hosts with a guaranteed vCPU share under 100% (burstable): 150 seconds.

Note

The most appropriate multiple units (MB, GB, and more) are automatically used in charts.

You can configure alerts in Yandex Monitoring to receive notifications about cluster failures. In Yandex Monitoring, there are two alert thresholds: Warning and Alarm. If the specified threshold is exceeded, you will receive alerts via the configured notification channels.

To identify potential issues in a cluster, use other cluster diagnostic tools alongside monitoring.

Cluster status monitoring

To view detailed information on the state of a Managed Service for PostgreSQL cluster:

  1. Go to Managed Service for PostgreSQL.

  2. Click the name of your cluster and open the Monitoring tab.

  3. To get started with Yandex Monitoring metrics, dashboards, or alerts, click Open in Monitoring in the top panel.

You will see the following charts:

  • Age of oldest transaction/statement: Oldest transaction/statement execution time.

  • Average transaction/statement time: Average transaction/statement processing time.

  • CPU usage: Processor core utilization.

  • Disk read/write bytes: Speed of disk read and write operations (bytes per second).

  • Disk read/write IOPS: Intensity of disk read and write operations (operations per second).

  • Disk usage by DB: Disk space utilization, broken down by database (bytes).

  • Disk usage on primary: Disk space utilization on the master host (bytes).

  • Inode usage by host: Number of inodes used by each host.

  • Inode usage on primary: Number of inodes used on the master host.

  • Is Primary, [boolean]: Shows which host is the master and for how long.

  • Free space: Free disk space, broken down by host (bytes).

  • Log errors: Number of errors logged per second.

  • Memory usage: RAM utilization (bytes). At high loads, the value of the Free metric decreases, while the others increase.

  • Network received/sent bytes: Network data transfer speed (bytes per second).

  • OOM Count: Indicates the presence of Out-Of-Memory Killer processes. These processes kill memory-exhausting applications, which prevents the OS from crashing.

  • Packets received/sent: Network packet rate (packets per second).

  • Pooler is alive, [boolean]: Connection pooler health for each host either as a master or as a replica.

  • PostgreSQL Alive, [boolean]: PostgreSQL health for each host either as a master or as a replica.

  • Replication lag: Replication delay time.

    Warning

    The replication lag is calculated with one-second accuracy. A lag of less than one second cannot be tracked using this metric.

  • Session CPU usage cores: Number of used processor cores, broken down by session type.

  • Sessions per wait event: Number of waiting sessions, broken down by wait event type.

  • Sessions read bytes: Volume of data read in bytes, broken down by session type.

  • Sessions write bytes: Volume of data written in bytes, broken down by session type.

  • Statement quantiles: Statement execution time, broken down by percentile.

  • TCP connections: Number of TCP connections per second.

  • Total pooler connections: Number of pooler connections, both client and server.

  • Total size of temporary files: Total size of temporary files in bytes.

  • Total size of WAL files: Total size of WAL files in bytes.

  • Transaction quantiles: Transaction processing time, broken down by percentile.

  • Transactions/statements per second: Number of transactions and statements per second.

Host status monitoring

To view detailed information on the state of individual Managed Service for PostgreSQL hosts:

  1. Go to Managed Service for PostgreSQL.
  2. Click the name of your cluster and select the Hosts → Monitoring tab.
  3. Select the host you need from the drop-down list.

This page displays the charts showing workloads of individual cluster hosts:

  • CPU usage: Processor core workload. With increased workload, the Idle value drops.
  • Disk IOPS: Number of disk operations per second.
  • Disk read/write bytes: Speed of disk operations in bytes per second.
  • Memory usage: RAM utilization in bytes. At high loads, the value of the Free metric decreases, while the others increase.
  • Network bytes: Network data transfer speed in bytes per second.
  • Network packets: Number of packets transferred over the network, per second.

The Disk read/write bytes and the Disk IOPS charts show the increase of the Read metric during database read activity, and the increase of the Write metric during database write activity..

For Replica hosts, the value of the Received metric on the Network Bytes and Network Packets charts is usually higher than the Sent metric.

Setting up alerts in Yandex Monitoring

  1. In the management console, select the folder containing the cluster for which you want to set up alerts.
  2. Go to Monitoring.
  3. Under Service dashboards, select:
    • Managed Service for PostgreSQL — Cluster Overview to set up cluster alerts.
    • Managed Service for PostgreSQL — Host Overview to set up host alerts.
  4. Locate the chart you need, click its icon, and select Create alert.
  5. If the chart shows multiple metrics, select the data query to generate a metric and click Continue. You can learn more about the query language in the Yandex Monitoring guides.
  6. Set the Alarm and Warning thresholds to trigger the alert.
  7. Click Create alert.

To have other cluster health indicators monitored automatically:

  1. Create an alert.
  2. Add a status metric.
  3. In the alert parameters, set the alert thresholds.

Below are recommended thresholds for some metrics:

Metric Parameter Alarm Warning
Replication delay postgres-replication_lag 60 5
Number of healthy hosts postgres-is_alive <number_of_hosts> - 2 <number_of_hosts> - 1
Average query execution time pooler-avg_query_time — 2,000
Storage space used disk.used_bytes 90% of the storage size 80% of the storage size

For the disk.used_bytes metric, the Alarm and Warning thresholds are only set in bytes. For example, the recommended values for a 100 GB disk are as follows:

  • Alarm: 96,636,764,160 bytes (90%).
  • Warning: 85,899,345,920 bytes (80%).

You can check the current storage size in the cluster details. For a complete list of supported metrics, see this Monitoring article.

Cluster health and status

The State of a cluster shows the health of its hosts, while the Status shows whether the cluster is started, stopped, or is at an intermediate stage.

To check the cluster’s health and status:

  1. Navigate to the folder dashboard and select Managed Service for PostgreSQL.
  2. Locate the cluster you need in the list, and hover over the indicator in the Availability column.

Cluster health

State Description Suggested actions
ALIVE Cluster is operating normally. No action is required.
DEGRADED Cluster is not running at its full capacity: the state of at least one of the hosts is other than ALIVE. Run the diagnostics:
  • Go to the Hosts tab and see which hosts are not working.
  • Go to the Operations tab and make sure all operations are completed.
  • Make sure the cluster is not under maintenance.
If you cannot find the cause yourself, contact support.
DEAD The cluster is down: none of its hosts are running. Make a support request stating the following:
  • Cluster ID.
  • IDs of the last operations performed on it.
  • Time the cluster entered the DEAD state according to the availability charts.
UNKNOWN Cluster state is unknown. Make a support request stating the following:
  • Cluster ID.
  • IDs of the last operations performed on it.
  • Time the cluster entered the UNKNOWN state according to the availability charts.

Cluster statuses

Status Description Suggested actions
CREATING Preparing for the first start Wait a while and get started. The time it takes to create a cluster depends on the host class.
RUNNING The cluster is operating normally No action is required.
STOPPING The cluster is stopping After a while, the cluster status will switch to STOPPED and the cluster will be disabled. No action is required.
STOPPED The cluster is stopped Start the cluster to get it running again.
STARTING Starting the cluster that was stopped earlier After a while, the cluster status will switch to RUNNING. Wait a while and get started.
UPDATING Updating the cluster's configuration Once the update is complete, the cluster will get the status it had prior to the update: RUNNING or STOPPED.
ERROR Error when performing an operation with the cluster or during a maintenance window If the cluster remains in this status for a long time, contact support. You can see whether a cluster is available by its status.
STATUS_UNKNOWN The cluster is unable to determine its status If the cluster remains in this status for a long time, contact support.
Previous
Performance diagnostics
Next
Connecting to DataLens