Retention and latency of metric data

This page provides information about how long Cloud Monitoring retains your metric data, and information about the latency between the collection of the data and its visibility to you.

Quotas and limits provides additional information about limits on metric data.

Retention of metric data

Cloud Monitoring acquires metric data and holds it in the time series of metric types for a period of time. This period of time varies with the metric type; See Data retention for details.

At the end of that period, Monitoring deletes the expired data points.

When all the points in a time series have expired, Monitoring deletes the time series. Deleted time series don't appear in Monitoring charts or in results from the Monitoring API.

Latency of metric data

Latency refers to the delay between when Monitoring samples a metric and when the metric data point becomes visible as time series data. The latency varies according to the monitored resource and other factors:

  • The descriptions of metric types included on the Metrics list often include a statement like this: “Sampled every 60 seconds. After sampling, data is not visible for up to 240 seconds.”

    This means that Monitoring collects one measurement each minute (the sampling rate), but it can take up to 4 minutes before you can retrieve the data (latency). So, the timestamp recording the collection time might be up to 4 minutes old.

    For example, consider the client library for Python. The time-series query method field labeled minutes specifies the time interval that the query covers. When you set minutes=5, then the query retrieves data in the time interval (now - 5 minutes, now]. Due to the latency of metric data, we recommend that you set this field to minutes=5.

  • If you are using user-defined metrics and you use the Monitoring API to write a new data point to an existing time series, then you can retrieve the data in a few seconds.

    In contrast, when you write the first data point to a new time series, you might have to wait a couple of minutes before you can retrieve the data. Writing a data point to a non-existent time series initiates the creation of the time series, and that takes some extra time.

Latency can affect incident creation time for metric-based alerting policies. For example, if a monitored metric has a latency of up to 180 seconds, then Monitoring won't create an incident for up to 180 seconds after the alerting policy condition evaluates to true.