Monitor Cloud SQL instances

MySQL  |  PostgreSQL  |  SQL Server

This page describes how you can monitor Cloud SQL instances in the following ways:

Monitor an instance by using the Cloud Monitoring dashboard

Cloud Monitoring offers predefined dashboards for several Google Cloud products,including a default Cloud SQLmonitoring dashboard. You canuse this dashboard to monitor the general health of your primary and replica instances.You can also create your owncustom dashboardsto display data that's of interest to you.

Set up alerts

You can use Cloud Monitoring toset up alertsfor a project or a specified instance.

For example, you can set up an alert for a message to be sent to specific emailIDs when theMemory usage metric for a Cloud SQL instance exceedsthe threshold of 80%.

View metrics on the Cloud SQL instance Overview page

View some of the key metrics for a Cloud SQL instance on its Overview page as follows:

  1. In the Google Cloud console, go to theCloud SQL Instances page.

    Go to Cloud SQL Instances

  2. To open theOverview page of an instance, click the instance name.
  3. The default metrics chart appears at the top of the page.

  4. Optional: Select another metric from theChart drop-down list.

    The chart shows the data for the selected metric.

The list includes the following options:
  • CPU utilization
  • Storage usage
  • Memory usage
  • Read/write operations
  • Ingress/Egress bytes
  • Replication lag (for read replicas)
  • Available metrics

    The usage charts help you respond proactively as your application needs change.From these metrics, you can gain insights into issues of throughput and latencyas well as instance usage costs.

    MetricDescription
    Storage usage (GB)

    You can use the storage usage metric to help you understand your storage costs. For more information about storage usage charges, seeStorage and Networking Pricing.

    Cloud SQL uses transaction logs forpoint-in-time recovery (PITR). These logs use storage space, and are deleted automatically with their associated automatic backups. This happens after the value set fortransactionLogRetentionDays is met. This value is the number of days of transaction logs that Cloud SQL retains for PITR. You can't delete these logs manually, but you can change the number of days to retain them, from 1 to 35 for Cloud SQL Enterprise Plus edition and 1 to 7 for Cloud SQL Enterprise edition.

    For instances that have transaction logs stored in Cloud Storage, the logs are stored in the same region as the primary instance. This log storage (up to seven days, the maximum length for PITR) generates no additional cost per instance.

    If the size of your transaction logs is causing an issue for your instance, then increase your storage size. However, the transaction log size increase in the disk usage might be temporary. If your instance has point-in-time recovery enabled, then deactivate and re-enable PITR to ensure that logs are stored in Cloud Storage in the same region as the instance. This deletes the logs, so you can't perform a point-in-time-restore earlier than the time that you re-enabled PITR. However, although the existing logs are deleted, the disk size remains the same.

    To avoid unexpected storage issues, we recommend enablingautomatic storage increases for all instances when using PITR. This recommendation applies only if your instance has PITR enabled and your logs are stored on disk.

    To delete the logs and recover storage, you can deactivate and then re-enable PITR. Decreasing the logs used doesn't shrink the size of the disk provisioned for the instance.

    Temp data is included in the storage usage metric. Temp data is removed as part of maintenance and is allowed to increase beyond user-defined capacity limits to avoid a disk full event, at no charge to the user.

    Data usage is also included in the storage usage metric. As part of data usage, when a transaction modifies a database, before Cloud SQL modifies the original data, a copy is made of this data. The copy of the data isundo data.

    A newly created database uses about 100 MB for system tables and files.

    CPU usage

    You can use this metric to monitor whether your instance has sufficient CPU for your application needs. If this value is running too high, you can increase the size of your machine type to give your instance more CPU capability.

    Memory usage

    The amount of memory being used by your instance.

    Read/write operations

    The Number of Reads metric is the number of read operations served from disk that do not come from cache. You can use this metric to help you understand whether your instance is correctly sized for your environment. If needed, you can move to a larger machine type to serve more requests from cache and reduce latency.

    The Number of Writes metric is the number of write operations to disk. Write activity is generated even if your application is not active, because Cloud SQL instances write to a system table approximately every second (except for replicas).

    Ingress/Egress bytes (bytes/sec)The amount of network traffic coming into or leaving the instance.

    Compare metrics from multiple instances

    1. In the Google Cloud console, go to theCloud SQL Instances page.

      Go to Cloud SQL Instances

    2. From the Cloud SQLInstances page, choose up to five instances to compare by selecting the checkbox to the left of the instance name.
    3. On theInfo Panel on the right, select theMonitoring tab.
    4. From the metrics drop-down, select the metric to use for comparing instances.

      You can see the data for a specific moment by holding the pointer over the chart.

    What's next

    Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

    Last updated 2025-11-24 UTC.