Stay organized with collections
Save and categorize content based on your preferences.
This page describes some of the user-controlled configurations that can cause an
outage for an AlloyDB for PostgreSQL cluster to be excluded from the
AlloyDB Service Level Agreement (SLA), which excludes outages
"caused by factors outside of Google's reasonable control."
AlloyDB gives you as much control over your
instance configuration as possible. However, customer-controlled configurations can
increase the risk of instance downtime, depending on the database load and other
configuration parameters.
If your instance becomes unhealthy, and if
Google determines that the instance is out of compliance with the
operational limits described in this page, then any resulting downtime is not
covered by (or does not count against) the AlloyDB
SLA.
The operational limits described in this page include the following
information:
Configurations that might result in a cluster being excluded from the
AlloyDB SLA.
How to avoid these types of configurations.
How to mitigate the risks when a configuration that might result in SLA
exclusion is required for your business environment.
Excluded configurations
Excluded configurations belong to the following categories:
General configuration requirements
Database flag values
Resource constraints
General configuration requirements
Only AlloyDB instances configured for high availability (HA) are
covered by the AlloyDB SLA, excluding the
1 vCPU shape (Preview).
Instances configured with 1 vCPU aren't covered by the AlloyDB
SLA, even if the instances are configured with
high availability (HA).
Basic (single-zone configured) instances are not covered by the SLA.
If the instance is configured and used in a way that causes the workload to
overload the instance, or if the configuration causes the instance to
experience a long recovery time, then the SLA does not apply.
Downtime of instances or clusters that results from your voluntary actions or
inactions is excluded.
Disabling the AlloyDB API
and other Google Cloud APIs that are required to create and connect to
AlloyDB is not considered downtime, and is not covered by
the SLA.
If you use VPC Service Perimeter configurations that aren't supported by
AlloyDB, any downtime resulting from these unsupported configurations is
exempt from the SLA. To learn about supported VPC Service Perimeter
configurations, see Configure VPC Service Controls.
For clusters using Customer-Managed Encryption Keys (CMEK),
the SLA does not cover downtime caused by the key becoming inaccessible to the AlloyDB service.
This key unavailability can occur if you disable, destroy, or revoke permissions for the key.
We recommend that you set up alerts and monitoring in
Cloud Monitoring.
Database flag values
AlloyDB lets you configure your instance using
database flags.
Incorrectly setting autovacuum and max_wal_size can cause performance
issues, increased disk space usage, and even instance crashes.
For a list of configurable flags and their defaults, see
database flags.
Resource constraints
To maintain AlloyDB SLA coverage, you must avoid the following
resource constraints:
Storage full: if your disk utilization is consistently high, and
you incorrectly configured your storage quota (which results in a storage
full issue), your instance is not properly sized for your workload and
the instance might not be covered by the SLA.
CPU overloaded: if your CPU utilization is consistently high, your
instance is not properly sized for your workload, and the instance might
not be covered by the SLA.
Memory overloaded: if your memory usage is consistently high, even though
AlloyDB provides automatic memory management, your instance
is not properly sized for your workload, and the instance might not be covered by the
SLA.
Connections overload: If your instance experiences constant
connection storms that cause the instance to be unstable, you might not
have configured the instance with a connection pooler, and the instance
might not be covered by the SLA.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-26 UTC."],[[["\u003cp\u003eThis document outlines user-controlled configurations that can cause an AlloyDB for PostgreSQL cluster outage to be excluded from the AlloyDB Service Level Agreement (SLA).\u003c/p\u003e\n"],["\u003cp\u003eThe AlloyDB SLA does not cover outages resulting from factors outside of Google's control, including instances that are not configured for high availability (HA) or are used in ways that overload them.\u003c/p\u003e\n"],["\u003cp\u003eIncorrect settings of database flags, such as \u003ccode\u003eautovacuum\u003c/code\u003e and \u003ccode\u003emax_wal_size\u003c/code\u003e, can lead to performance issues, increased disk usage, and instance crashes, potentially excluding the instance from SLA coverage.\u003c/p\u003e\n"],["\u003cp\u003eResource constraints, including storage full, CPU overloaded, memory overloaded, and connection overloads, can result in an instance not being properly sized for the workload and therefore not covered by the SLA.\u003c/p\u003e\n"],["\u003cp\u003eDowntime caused by voluntary actions or inactions, disabling required APIs, or using unsupported VPC Service Perimeter configurations are not considered downtime and are excluded from the AlloyDB SLA.\u003c/p\u003e\n"]]],[],null,["# AlloyDB for PostgreSQL operational guidelines\n\nThis page describes some of the user-controlled configurations that can cause an\noutage for an AlloyDB for PostgreSQL cluster to be excluded from the\nAlloyDB [Service Level Agreement (SLA)](/sql/sla), which excludes outages\n\"caused by factors outside of Google's reasonable control.\"\n\nAlloyDB gives you as much control over your\ninstance configuration as possible. However, customer-controlled configurations can\nincrease the risk of instance downtime, depending on the database load and other\nconfiguration parameters.\n\nIf your instance becomes unhealthy, and if\nGoogle determines that the instance is out of compliance with the\noperational limits described in this page, then any resulting downtime is not\ncovered by (or does not count against) the AlloyDB\n[SLA](/alloydb/sla).\n\nThe operational limits described in this page include the following\ninformation:\n\n- Configurations that might result in a cluster being excluded from the AlloyDB SLA.\n- How to avoid these types of configurations.\n- How to mitigate the risks when a configuration that might result in SLA exclusion is required for your business environment.\n\n| **Note:** You are responsible for monitoring your instance to ensure that it's correctly sized and configured for the type of workload that you're running.\n\nExcluded configurations\n-----------------------\n\nExcluded configurations belong to the following categories:\n\n- General configuration requirements\n- Database flag values\n- Resource constraints\n\nGeneral configuration requirements\n----------------------------------\n\n- Only AlloyDB instances configured for high availability (HA) are\n covered by the AlloyDB [SLA](/alloydb/sla), excluding the\n 1 vCPU shape ([Preview](https://cloud.google.com/products?e=48754805product-launch-stages)).\n\n- Instances configured with 1 vCPU aren't covered by the AlloyDB\n [SLA](/alloydb/sla), even if the instances are configured with\n high availability (HA).\n\n- Basic (single-zone configured) instances are not covered by the SLA.\n\n- If the instance is configured and used in a way that causes the workload to\n overload the instance, or if the configuration causes the instance to\n experience a long recovery time, then the SLA does not apply.\n\n- Downtime of instances or clusters that results from your voluntary actions or\n inactions is excluded.\n\n- Disabling the [AlloyDB API](/alloydb/docs/quickstart/create-and-connect#before-you-begin)\n and other Google Cloud APIs that are required to create and connect to\n AlloyDB is not considered downtime, and is not covered by\n the SLA.\n\n- If you use VPC Service Perimeter configurations that aren't supported by\n AlloyDB, any downtime resulting from these unsupported configurations is\n exempt from the SLA. To learn about supported VPC Service Perimeter\n configurations, see [Configure VPC Service Controls](/alloydb/docs/vpc-sc/configure-vpc-service-controls).\n\n- For clusters using Customer-Managed Encryption Keys (CMEK),\n the SLA does not cover downtime caused by the key becoming inaccessible to the AlloyDB service.\n This key unavailability can occur if you disable, destroy, or revoke permissions for the key.\n\n- We recommend that you set up alerts and monitoring in\n [Cloud Monitoring](/alloydb/docs/monitor-instance).\n\nDatabase flag values\n--------------------\n\nAlloyDB lets you configure your instance using\n[database flags](/alloydb/docs/instance-configure-database-flags).\nIncorrectly setting `autovacuum` and `max_wal_size` can cause performance\nissues, increased disk space usage, and even instance crashes.\n\nFor a list of configurable flags and their defaults, see\n[database flags](/alloydb/docs/reference/database-flags).\n\nResource constraints\n--------------------\n\nTo maintain AlloyDB SLA coverage, you must avoid the following\nresource constraints:\n\n- **Storage full** : if your disk utilization is consistently high, and\n you incorrectly configured your storage quota (which results in a storage\n full issue), your instance is not properly sized for your workload and\n the instance might not be covered by the [SLA](/alloydb/sla).\n\n- **CPU overloaded** : if your CPU utilization is consistently high, your\n instance is not properly sized for your workload, and the instance might\n not be covered by the [SLA](/alloydb/sla).\n\n- **Memory overloaded** : if your memory usage is consistently high, even though\n AlloyDB provides automatic memory management, your instance\n is not properly sized for your workload, and the instance might not be covered by the\n [SLA](/alloydb/sla).\n\n- **Connections overload** : If your instance experiences constant\n connection storms that cause the instance to be unstable, you might not\n have configured the instance with a connection pooler, and the instance\n might not be covered by the [SLA](/alloydb/sla).\n\nWhat's next\n-----------\n\n- Learn [best practices for improving AlloyDB performance and availability](/alloydb/docs/best-practices-improve-performance-availability)."]]