• Pricing examples.
• Estimate your bills.
• Optimize and monitor your costs.

The following tables summarize the pricing information for Cloud Logging,Cloud Monitoring, and Cloud Trace.

Cloud Logging pricing summary

^* Storage volume counts the actual size of the log entries prior to indexing.There are no storage charges for logs stored in the_Required log bucket.

^† Vended logs are Google Cloud networking logs that are generated by Google Cloud serviceswhen the generation of these logs is enabled. Vended logs includeVPC Flow Logs, Firewall Rules Logging,and Cloud NAT logs. These logs are also subject toNetwork telemetry pricing. For moreinformation, seeVended logs.

^‡ There are no retention charges for logs stored in the_Required log bucket,which has a fixed retention period of 400 days.

^♣ Log routing is defined as forwarding logs received through the Cloud Logging API to asupported destination. Destination charges might apply to routed logs.

^♥ There is no charge to upgrade a log bucket to use Log Analytics or to issue SQL queriesfrom theLog Analytics page.

Note: The pricing language for Cloud Logging changed on July 19, 2023;however, the free allotments and the rates haven't changed. Your bill might refer to the oldpricing language.

Cloud Monitoring pricing summary

^† Google Cloud Managed Service for Prometheus usesCloud Monitoring storage for externally created metric data and usesthe Monitoring API to retrieve that data.Google Cloud Managed Service for Prometheus meters based on samples ingested instead ofbytes to align with Prometheus' conventions. For more information about sample-basedmetering, seeOptimize costs for Google Cloud Managed Service for Prometheus. For computational examples, seePricing examples based on samplesingested.
^# Samples are counted per billing account.
^‡ Executions are charged to the billing account in which they are defined.For more information, seePricing for uptime-check execution.
^* Executions are charged to the billing account in which they are defined.For each execution, you might incur additional charges from other Google Cloud services,including services such as Cloud Run functions, Cloud Storage, and Cloud Logging.For information about these additional charges,see the pricing document for the respective Google Cloud service.
^♣ For more information, seePricing for alerting.
^♥ There is no charge for read API calls issued through the Google API Console,excluding those issued through the Cloud Shell.Read API calls that aren't issued through the Google API Console and that can return time-series dataare charged by the number of time series that are returned or for one time series,which ever is larger. There is no charge for other read API calls. For more information, seeCloud Monitoring API pricing.

Cloud Trace pricing summary

For detailed information about the costs for Google Cloud Observability products, seethe following sections of this page:

• Cloud Logging
• Cloud Monitoring
• Error Reporting
• Cloud Profiler
• Cloud Trace

Cloud Logging

Log buckets are the Logging containers that store logs data.Logging charges for the volume of log data that is storedin the_Default log bucket and in user-defined log buckets.Pricing applies to non-vended network logs when the volume exceeds thefree monthly allotment,and tovended network logs.

For the_Default log bucket and for user-defined log buckets,Logging also charges when logs areretained for more than thedefault retention period, which is30 days.

There are no additional charges by Logging for thefollowing:

• Routing logs.
• Using the Cloud Logging API.
• Creatinglog scope.
• Creatinganalytics views.
• Logs stored in the_Required log bucket,which has a fixed retention period of 400 days.

This section provides information about the following topics:

• Cloud Logging storage model
• Storage pricing
• Retention pricing
• Vended network logs pricing
• Log-based metrics pricing

For limits that apply to your use of Logging, including dataretention periods, seeQuotas and limits.

Cloud Logging storage model

For each Cloud project, Logging automaticallycreates two log buckets:_Required and_Default.For these two buckets, Logging automatically creates log sinksnamed_Required and_Default that route logs to the correspondingly namedlog buckets. You can't disable or modify the_Required sink. You can disableor otherwise modify the_Default sink to prevent the_Default bucket fromstoring new logs.

You cancreate user-defined log buckets in any of your Cloud projects. You can also configure sinks to routeany combination of logs, even across Cloud projects in yourGoogle Cloud organization, to these log buckets.

For the_Default log bucket and for user-defined log buckets, you canconfigure a custom retention period.

You can upgrade your log buckets to useLog Analytics.There is no charge to upgrade a log bucket to use Log Analytics.

For more information on Cloud Logging buckets and sinks, seeRouting and storage overview.

Storage pricing

Logging charges the project where the logs are streamed intolog buckets for storage, after the free monthly allotment is exceeded.For each project, charges are based on the volume of logs streamed intoits user-defined log buckets and its_Default log bucket.

Logging doesn't charge for routing logs. Suppose a log entryoriginates in a project but the project doesn't store the log entry in oneof its log buckets. In this scenario, the project isn't charged for the logentry. However, if the project routes the log entry to a log bucket in anotherproject, then the destination project is charged for that log entry.

When a log entry is written to any log bucket except the_Required logbucket, the project that contains that log bucket is charged for the storageof that log entry. For example, if a log entry is routed to three log bucketsthat are in the same project, then that project is charged three times for thelog entry. Similarly, if a log entry is routed to two log buckets, but theselog buckets are in different projects, then the projects that store those logbuckets are each charged for one log entry.

Logging doesn't charge for logs stored in the_Required bucket.You can't delete the_Required bucket or modify the_Required sink.The_Required bucket stores the following logs:

• Admin Activity audit logs
• System Event audit logs
• Google Workspace Admin Audit logs
• Enterprise Groups Audit logs
• Login Audit logs
• Access Transparency logs. For information about enabling Access Transparency logs, see theAccess Transparency logs documentation.

Vended network logs are available only when you configure log generation.The services that generate vended network logs charge for log generation.If you store these logsin a log bucket or route them to another supported destination, then youare also subject to charges from Cloud Logging or the destination.For information about log-generation costs, seeNetwork telemetry pricing.

To learn how to enable vended network logs, seeConfigure VPC Flow Logs,Use Firewall Rules Logging,andCloud NAT: Logs and metrics.

To find your vended network logs, in the Logs Explorer filter by thefollowing log names:

• projects/<var>PROJECT_ID</var>/logs/compute.googleapis.com%2Fvpc_flows
• projects/<var>PROJECT_ID</var>/logs/compute.googleapis.com%2Ffirewall
• projects/<var>PROJECT_ID</var>/logs/compute.googleapis.com%2Fnat_flows
• projects/<var>PROJECT_ID</var>/logs/networkmanagement.googleapis.com%2Fvpc_flows

Logs-based metrics pricing

System-defined logs-based metrics areprovided for all Cloud projects and are non-chargeable.

User-defined logs-based metrics are a class of Cloud Monitoring custom metrics and are chargeable. Forpricing details, seeChargeable metrics.

Cloud Monitoring

Monitoring charges for the following:

• Metrics measured by bytes ingested, when the ingested metric data exceedsthe free monthly metric allotment.

  Non-chargeable metrics don't count towards the allotment limit.

• Metrics measured by number of samples ingested.

• Cloud Monitoring API read calls that exceed the free monthly API allotment.

  Monitoring API write calls don't count towards the allotmentlimit.

• Execution of uptime checks.

• Execution of synthetic monitors.

• Alerting policy conditions measured by number of active conditions per month.

• Time series returned by the query of an alerting policy condition.

In Monitoring,ingestion refers to the process ofwriting time series to Monitoring. Each time seriesinclude some number of data points; those data points are the basis foringestion charges. For pricing information, seeCloud Monitoring pricing.

This section provides the following information:

• Cloud Monitoring API pricing.
• Definitions ofchargeable andnon-chargeable metrics.
• Descriptions ofbyte- andsample-based ingestion strategies.

For limits that apply to your use of Monitoring,seeQuotas and limits.

Cloud Monitoring API pricing

There is no charge for Monitoring write API calls.

From July 1, 2018 through October 1, 2025,Monitoring read API calls are charged one unit per call.

From October 2, 2025,Monitoring read API costs are determined by the number oftime series returned:

• There is no charge for read API calls issued through the Google API Console,excluding those issued through the Cloud Shell.

• There is no charge for read API calls that can't return time-series data.

• All other read API calls are charged bythe number of time series that are returned or for one time series,which ever is larger. For example, a call totimeSeries.listmight return multiple time series. The Cloud Monitoring APIcan be invoked indirectly. For example, Google Cloud CLI commands,client libraries, and third-party tools like Grafana might issue read APIcommands.

  You can use thetime_series_billed_for_queries_countmetric to monitor the number of time series that have been queried. For moreinformation, seeView the number of time series billedfor queries.

Non-chargeable metrics

Metric data from Google Cloud and Knative isn't chargeable. Non-chargeable (free) metrics include the following:

• Google Cloud metrics. For additional information,seeFootnote 2.
• Istio metrics
• Knative metrics
• Google Kubernetes Engine system metrics
• agent.googleapis.com/agent/ metrics

Chargeable metrics

All metric data, except for those metrics listed in the section titledNon-chargeable metrics, is chargeable.Most metric ingestion is charged by the number of bytes, but some is charged bythe number of samples; these pricing models are described in the followingsections.

The following factors contribute to ingestion costs:

• The type of data points—scalar values or distributionvalues—collected by the metrics.

  • For information about the data type associated with a specificmetric type, see thelist of metrics.
  • For information about scalar and distribution data types, seeValue types.

• The number of data points written to time series. This value depends on thefrequency with which the data is sampled and the cardinality of yourdata. The cardinality determines how many time series are generated fora combination of metric and monitored-resource types; for more information,seeCardinality.

The values for the metric and resource labels that are part of your timeseries don't contribute to your charges.

Metrics charged by bytes ingested

The following metrics are chargeable and priced by the number of bytes ingested:

• Agent metrics underagent.googleapis.com,except theagent.googleapis.com/agent/ group

  As of August 6, 2021, theagent.googleapis.com/processes/ metricswill be charged at5% of the volumerate for other chargeable metrics. For example, ingesting 100 MiBof process metrics will cost the same as ingesting 5 MiB of otherchargeable metrics.³

• Metrics fromthird-party integrations with the OpsAgent. These metricsare ingested into Cloud Monitoring with identifiersof the formworkload.googleapis.com/APPLICATION.METRIC;for example, the metric typeworkload.googleapis.com/nginx.requests fallsinto this category.

• OpenTelemetry Protocol (OTLP) metrics ingested into Cloud Monitoring asworkload.googleapis.com metrics by the Ops Agent. This is a configurationoption; for more information, seeIngestion formats for OTLPmetrics.

• Custom metrics,including but not limited to those metrics sent by using theCloud Monitoring API or language-specific client libraries, OpenCensus, andOpenTelemetry.

• External metrics

• User-defined logs-based metrics

For pricing purposes, the ingestion volume is computed as follows:

• For a scalar data type: 8 bytes for each data point writtento a time series.User-defined logs-based counter metrics fall into this category.
• For a distribution data type: 80 bytes for each data point writtento a time series.

For information about data points in time series,seeTime series: data from a monitored resource.

Metrics charged by samples ingested

The following metrics are chargeable and priced by the number of samplesingested:

• Metrics fromGoogle Cloud Managed Service for Prometheus:prometheus.googleapis.com metrics.

For pricing purposes, the sample count is computed as follows:

• For a scalar data type: 1 for each point written to a time series.
• For a distribution data type: 2 for each point written to a time series,plus 1 for each histogram bucket that has a non-zero count.

For information about data points in time series,seeTime series: data from a monitored resource.

Pricing for uptime-check execution (Effective date: October 1, 2022)

Monitoring charges for each regional execution of an uptimecheck, beyond the free monthly allotment of 1 million executions.A check that executes in three regions counts as three executions.

The cost for uptime-check execution is $0.30/1,000 executions.The charge appears on your bill as SKU "CA14-D3DE-E67F"for "Monitoring Uptime Checks".

Pricing for synthetic-monitor execution (Effective date: November 1, 2023)

Cloud Monitoring charges for each execution of a synthetic monitor, beyondthe free allotment per month of 100 executions per billing account.

Pricing for alerting

Starting no sooner than May 1, 2026, Cloud Monitoringwill begin charging foralerting.The pricing model is as follows:

• $0.10 per month for each condition in an alerting policy.
• $0.35 per 1,000,000 time series returned by the query of a metric alerting policy condition.

• Definitions of alerting terminology.
• Information aboutopting out of billingfor alerting policies.

Definitions

• Condition: Thecondition of analerting policy describes when a resource, or a group of resources,is in a state that requires a response.

  • Alerting policies that use filters to createmetric-threshold ormetric-absence queries cancombine up to six conditions.
  • Alerting policies with a the following query types can have only asingle condition:
    • Prometheus Query Language (PromQL) query,
    • Monitoring Query Language (MQL)
    • Log match, used inlog-based alerts.

  The charge is for each condition $0.10 per month.To stop being charged for a condition, you must delete the alerting policy.Snoozing ordisabling the policy doesn'tstop you from being charged.

• Metric andlog-based alerting policies: Alerting policies that useany condition type except log-match conditions aremetric alertingpolicies; the conditions of metric alerting policies return time series.During each execution period, conditions in metric alerting policies executetheir queries against the Cloud Monitoring datastore. The returnedtime series are then evaluated against a threshold to determine whether thealerting policy fires.

  Log-based alerting policies use log-match conditions. Log-match conditionsreturn no time series.

  Metric alerting policies that use Billing, Quota, or Uptime metrics are notcharged. Log-based alerting policies for Personalized Service Health logs are notcharged.

• Execution period: How frequently Cloud Monitoring executes yourcondition. For most condition types, this is 30 seconds and can't bechanged. Conditions that use a PromQL query can set this period.For more information, seeIncrease the length of the execution period(PromQL only).

• Time series returned: During every execution period, a metric alertingpolicy executes the query of its condition against the Cloud Monitoringdatastore. Cloud Monitoring returns time series data as a response toeach query. Each time series in the response counts as one time seriesreturned.

  The number of time series returned in a month is determined by three factors:

  • The shape and scope of the underlying data.
  • The filters and aggregations you use in the query of your condition.
  • The execution period.

Opting out

If you have an existing Google Cloud contract that doesn't expire untilMay 1, 2026, you can delay billing for alerting until your contractis due for renewal by requesting an exemption from the Cloud Monitoringalerting billing team. Exemptions for customers with active contracts will beconsidered on a case-by-case basis.

You can request an exemption untilNovember 1, 2025.To request a billing exemption until contract renewal, fill out thebilling-exemption request form.

Error Reporting

Error data can be reported to your Google Cloud project by using theError Reporting API or theCloud Logging API.

There are no charges for using Error Reporting.However, you might incur Cloud Logging costs because log entries aregenerated and then stored by Cloud Logging.

For limits that apply to your use of Error Reporting,seeQuotas and limits.

Cloud Profiler

There is no cost associated with using Cloud Profiler.

For limits that apply to your use of Profiler,seeQuotas and limits.

Cloud Trace

Trace charges are based on the number of tracespans ingested and scanned. Trace data can be ingested through theCloud Trace API or the Telemetry API. There are no charges to configuretrace scope.

When latency data is sent to Trace, it's packaged as atrace that is composed ofspans, and the spans areingested bythe Cloud Trace backend. When you view trace data, the stored spans arescanned by Cloud Trace.This section provides the following information:

• Defines chargeable and non-chargeable trace spans
• Provides a pricing example
• Provides information on how to reduce your trace span ingestion.
• Provides settings for an alerting policy that can notify you if yourtrace span ingestion reaches a threshold.

For limits that apply to your use of Trace,seeQuotas and limits.

Non-chargeable trace spans

Cloud Trace pricing doesn't apply to spans auto-generated byApp Engine Standard,Cloud Run functions orCloud Run:ingestion of these traces are non-chargeable.

Auto-generated traces don't consume Cloud Trace API quota, and these tracesare excluded from Cloud Trace API usage metrics.

Chargeable trace spans

Ingestion of trace spans except for those spans listed in the section titledNon-chargeable traces,are chargeable and are priced by ingested volume.

Frequently asked questions

Which product features are free to use?

Usage of Google Cloud Observability products is priced by data volume. Other than thedata volume costs described on this page, usage of all additionalGoogle Cloud Observability product features is free.

How much will I have to pay?

To estimate your usage costs,seeEstimating your bills.

To get help with billing questions, seeBilling questions.

How do I understand the details of my usage?

Several metrics let you drill into and understand your logs and metricsvolume using Metrics Explorer. seeView detailed usage in Metrics Explorer for details.

If you're interested in learning how to manage your costs, see these blogposts:

• Cloud Logging pricing for Cloud Admins: How to approach it & save cost
• Four steps to managing your Cloud Logging costs on a budget

How do metrics scope, log scope, and trace scope affect billing?

For the most part,metrics scope,log scope, andtrace scope don't affect billing.

Logs, metrics, and traces are charged by the project, billing account, folder,or organization thatreceives the data.The metrics scope for a project defines the collectionof the resources whose metrics the project can view and monitor. When youdefine a metrics scope, you don't affect which resource receives metricdata or cause data to be duplicated. A log scope only liststhe resources that store or route the log entries that you want to view.Similarly, a trace scope only lists the resources that store thetrace data that you want to view.

For example, suppose your organization has 100 virtual machines (VMs):60 VMs are hosted by Project-A and 40 VMs are in Project-B.Project-A receives and stores the metrics for its VMs, and it's charged whenmetrics are chargeable. Similarly, Project-B receives and stores the metrics forits VMs, and it's charged when metrics are chargeable.If you create a metrics scope that includes Project-A and Project-B, thenyou can view the combined metrics for your 100 VMs. You can now viewjust the metrics for Project-A, just the metrics of Project-B, or thecombination of metrics. Even though you have two ways to view the metricsof Project-A, there aren't billing implications.

What happens if I go over the free allotments?

You are automatically billed for any usage over your free allotments.You don't lose any logs or metrics. To better understand your potential costs,reviewEstimating your bills.

You cancreate an alerting policy that monitorsyour usage and notifies you when you approach the threshold forbilling.

I have a large number of Google Cloud logs in my project(s) that I donot use. I am concerned about charges for these logs. How do I avoid this?

You can exclude logs to control which logs are ingested intoLogging. SeeReducing your logs usage for details.

Will services that send logs to my project receive an error if logs areexcluded?

No. Services that send log entries cannot determine whether the logentries are ingested into Logging or not.

Will I be charged twice for Virtual Private Cloud flow logs?

If you send your VPC flow logs to Logging,VPC flow logs generation charges are waived, and onlyLogging charges apply. However, if you send them and then excludeyour VPC flow logs from Logging,VPC flow logs charges apply. For more information, seeGoogle Cloud Pricing Calculator and then select the tab titled "Cloud Load Balancing and Network Services".

¹For pricing purposes, all unitsare treated asbinary measures, for example, asmebibytes(MiB, or 2²⁰ bytes) orgibibytes(GiB, or 2³⁰ bytes).

²There is no charge for Google Cloud metrics that are measured at up to 1 data point per minute, the current highest resolution. In the future, metrics measured at higher resolutions might incur a charge.

³Process metrics are currently collected at a pre-defined default rate ofonce per minute, which can't be changed. This data generally changes slowly,so these metrics are currently over-sampled. Therefore, charging process metricsat 5% of the standard rate aligns with thestandard rate if the metrics were sampled at 20-minute intervals. Users whocollect 100 MiB of data from these metrics are charged for only 5 MiB.

What's next

• Read theGoogle Cloud Observability documentation.
• Try thePricing calculator.
• Learn aboutGoogle Cloud Observability solutions and use cases.