The Cloud SQL [Service Level Agreement (SLA)](https://cloud.google.com/sql/sla) excludes outages "caused by
factors outside of Google's reasonable control". This page describes some
of the user-controlled configurations that can cause an outage for a Cloud SQL
instance to be excluded.

For Cloud SQL engine-specific configurations, see the following pages
for engine-specific operational guidelines:

- [Cloud SQL for MySQL operational guidelines](https://docs.cloud.google.com/sql/docs/mysql/operational-guidelines.md.txt)
- [Cloud SQL for PostgreSQL operational guidelines](https://docs.cloud.google.com/sql/docs/postgres/operational-guidelines.md.txt)
- [Cloud SQL for SQL Server operational guidelines](https://docs.cloud.google.com/sql/docs/sqlserver/operational-guidelines.md.txt)

## Introduction

Cloud SQL strives to give you as much control over how your instance is
configured as possible. This includes some configurations that increase the risk
of instance downtime, depending on the load and other configuration parameters.
If your instance becomes unhealthy, and Cloud SQL determines that it was out of
compliance with the operational limits as described on this page, then the
downtime period is not covered by (or does not count against) the
Cloud SQL [SLA](https://cloud.google.com/sql/sla).

This list of operational limits is presented to inform you which configurations
present these risks, ways to avoid these
configurations, and ways to mitigate the risks when the configuration is
required for your business environment.

> [!NOTE]
> **Note:** You are responsible for monitoring your instance to ensure that it is properly sized and configured for the size and type of load it is experiencing.

## Excluded configurations

The excluded configurations fall into the following categories:

- General configuration requirements
- Database flag values
- Resource constraints

### General configuration requirements

Only Cloud SQL instances configured for high availability with at least one
dedicated CPU are covered by the Cloud SQL [SLA](https://cloud.google.com/sql/sla). Shared-core instances and single-zone
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 the instance to experience a long recovery time,
then the SLA does not apply.

We strongly advise you to set up alerts and monitoring
in [Cloud Monitoring](https://docs.cloud.google.com/sql/docs/mysql/monitor-instance.md.txt).

### Database flag values

Cloud SQL lets you configure your instance using [database
flags](https://docs.cloud.google.com/sql/docs/mysql/flags). Some of these flags can be set in ways that might compromise the
stability of the instance or the durability of its data.

For Cloud SQL engine-specific configurations, see the following pages for
engine-specific flags:

- [Cloud SQL for MySQL database flags](https://docs.cloud.google.com/sql/docs/mysql/flags.md.txt)
- [Cloud SQL for PostgreSQL database flags](https://docs.cloud.google.com/sql/docs/postgres/flags.md.txt)
- [Cloud SQL for SQL Server database flags](https://docs.cloud.google.com/sql/docs/sqlserver/flags.md.txt)

### Resource constraints

The following resource constraints must be avoided to retain SLA coverage:

- **Storage full** : if your disk utilization is consistently high, and automatic storage increase is not enabled, your instance is not properly sized for your workload and may not be covered by the [SLA](https://cloud.google.com/sql/sla).
- **CPU overloaded** : if your CPU utilization is consistently high, your instance is not properly sized for your workload, and may not be covered by the [SLA](https://cloud.google.com/sql/sla).
- **Memory overloaded** : if your memory usage is consistently high, your instance is not properly sized for your workload, and may not be covered by the [SLA](https://cloud.google.com/sql/sla).

For more information, refer to the [General best practices](https://docs.cloud.google.com/sql/docs/best-practices.md.txt).

<br />