Google Cloud Observability release notes

The following limits associated with the Cloud Trace API, cloudtrace.googleapis.com, have increased:

• Maximum attributes per span: 1,024
• Maximum attribute value size: 65,532 bytes
• Maximum attribute key size: 512 bytes
• Maximum span name length: 1,024 bytes
• Maximum events per span: 256

The new limits are consistent with those supported by the Telemetry API, which implements the OpenTelemetry Protocol (OTLP).

For more information, see Cloud Trace API quotas and limits.

The Telemetry API for logs ingestion is generally available (GA). You can ingest OTLP logs into Cloud Logging by using an OpenTelemetry Collector, an OTLP exporter, and the Telemetry API. For more information, see OTLP ingestion overview.

Error Reporting can report stack traces collected from Rust applications using std::backtrace. To enable, set the RUST_BACKTRACE=1 environment variable and make sure debug symbols are enabled.

For more information, see ReportedErrorEvent.

The following remote MCP servers automatically generate a trace span for tools/call operations. These spans can help you understand the behavior of your agentic applications. For more information, see Investigate MCP calls using Trace.

• Cloud Billing
• Personalized Service Health

Google Cloud Observability automatically generates trace exemplars for charts on custom dashboards that display the result of a SQL query when the query runs against your trace data and satisfies some constraints. The exemplars link the SQL query result to specific traces. This feature is in Preview.

For more information, see Generate and display trace exemplars.

The Telemetry API for metric ingestion is generally available (GA). You can ingest OTLP metrics into Cloud Monitoring by using an OpenTelemetry Collector, an OTLP exporter, and the Telemetry API. For more information, see OTLP metric ingestion overview.

Alerting policies based on PromQL queries can now operate over more than 25 hours of data. For more information, see Query over 2 years of metric data and Limits for alerting.

Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:

• europe-west9

For a list of supported locations, see Locations for observability buckets.

Support for applying role-based access controls (RBAC) to Cloud Monitoring dashboards and alerting policies using Tags is generally available.

You can use Tags to protect Terraform-managed Cloud Monitoring resources and configure team-scoped access. For more information, see Use Tags to control access to resources.

If the parent project for a Cloud Storage bucket changes, a log sink stops routing log entries to that bucket. For more information about error messages and recovery options, see Errors routing to Cloud Storage.

Metrics Explorer can automatically break down a chart into a series of tiles, with each displaying time-series data for a specific label key. This view helps you identify spikes, dips, or trends that the aggregation settings might otherwise hide.

To learn more, see Break down a chart by labels.

The Cloud Logging API adds support for the ca regional endpoint. For a complete list of regional endpoints, see the REST reference pages.

You can collect, view, and analyze multimodal prompts and responses from your agentic applications that use the LangGraph or Agent Development Kit (ADK) frameworks. This feature is generally available (GA).

• Instrument generative AI applications
• Collect and view multimodal prompts and responses

All agent.googleapis.com/processes metrics are retained for 24 months. For more information, see Data retention.

The Trace API supports regional endpoints. For a list of supported endpoints, see the REST API reference pages:

• v1 REST reference
• v2 REST reference

Custom dashboards can display trace data. You can view individual spans or aggregated data. This feature is public preview. For more information, see the following:

• Display trace data (Google Cloud console)
• Dashboard with trace data (API)

Custom dashboards can display trace data. You can view individual spans or aggregated data. This feature is public preview. For more information, see Display traces on a custom dashboard.

To view the instrumentation scope or the schema associated with a span, open the Details view for the span and select the Metadata & Links tab. For more information, see View attributes, log entries, and events.

Support for Histogram widgets on custom dashboards is generally available. These widgets extract the most recent value from each time series, group those values into ranges, and then provide a graphical representation of the result. Unlike tables or other widgets that display the most recent values, Histograms display information about the relative frequency of ranges of values.

This widget is one of several visualizations that you can use to display the most recent values. For more information, see the following documents:

• Configure a histogram (Google Cloud console)
• Dashboard with an XyChart configured as a histogram (API)

The create-observability bucket flow enforces organization policies with constraints on resource locations. This flow also enforces policies that require customer-managed encryption keys (CMEKs) and that restrict the projects that store those keys. Your trace data is stored in an observability bucket.

For more information, see the following:

• Set defaults for observability buckets
• Support for CMEKs

The details page for a span can display the call hierarchy of a trace by using a directed acyclic graph (DAG). If you view an Application Monitoring dashboard and explore the trace data that it displays, the flyout supports the DAG option. If you open the Trace Explorer page and explore a span, the DAG option is also available.

For more information, see the following:

• Application Monitoring: Explore a trace
• Trace Explorer: Explore a trace

The details page for a span can display the call hierarchy of a trace using a directed acyclic graph (DAG). One way to view a span's details is to open the Trace Explorer page and select the span. The DAG view is also available for some integrations. For example, if you view an Application Monitoring dashboard and explore the trace data it displays, the flyout supports the DAG option.

For more information, see the following:

• Trace Explorer: Explore a trace
• Application Monitoring: Explore a trace

You can view the available regional endpoints for the Cloud Logging API on the REST reference pages. For an example, see Method: projects.locations.buckets.list.

You can view the available regional endpoints for the Observability API and for the Telemetry API on their REST reference pages. For more information, see API overview.

You can view the available regional endpoints for the Error Reporting API on the REST reference pages. For an example, see Method: projects.events.list.

Cloud Trace in Observability Analytics is generally available (GA). Observability Analytics lets you query and analyze your trace data by using SQL. You can chart your query results, save your queries, and join your trace and log data.

For more information, see the following documents:

• Query and analyze telemetry with Observability Analytics.
• Chart SQL query results
• Sample SQL queries
• Analyze trace data with BigQuery.

The Observability API is generally available (GA). This API lets you configure the following:

• The default storage location and the default encryption key for your trace data.
• The observability scope.
• A linked BigQuery dataset, which lets your use BigQuery services to analyze your trace data.

For more information, see the following documents:

• Set defaults for observability buckets
• Configure observability scopes for multi-project queries
• Manage observability buckets
• API overview

Trace scopes are generally available (GA). For more information, see Create and manage trace scopes.

The following remote MCP servers automatically generate a trace span for tools/call operations. These spans can help you understand the behavior of your agentic applications. For more information, see Investigate MCP calls using Trace.

• BigQuery
• Cloud SQL

Starting with version 2.66.0, the Ops Agent can export your logs and metrics by using the OpenTelemetry-based Telemetry API rather than by using the Cloud Logging API and Cloud Monitoring API. During the preview Preview period, you can opt-in to using the Telemetry API. For more information, see Use the Telemetry API.

Starting with version 2.66.0, the Ops Agent can export your metrics and logs by using the OpenTelemetry-based Telemetry API rather than by using the Cloud Monitoring API and Cloud Logging API. During the preview Preview period, you can opt-in to using the Telemetry API. For more information, see Use the Telemetry API.

Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:

• asia-northeast1
• asia-southeast1
• me-west2
• southamerica-east1
• us-west4

For a list of supported locations, see Locations for observability buckets.

The following remote MCP servers automatically generate a trace span for tools/call operations. These spans can help you understand the behavior of your agentic applications. For more information, see Investigate MCP calls using Trace.

• Agent Search
• AlloyDB for PostgreSQL
• Google Security Operations

Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:

• australia-southeast1
• europe-central2
• europe-north1
• europe-southwest1
• europe-west2
• europe-west10
• europe-west12
• me-central2
• northamerica-northeast1
• us-east4

For a list of supported locations, see Locations for observability buckets.

Cloud Trace is a service covered by the Cloud Observability (Monitoring, Logging, Trace) Service Level Agreement (SLA).

The Cloud Monitoring API MCP server is generally available (GA). To learn about using the Monitoring MCP server to let agents and AI applications interact with your metrics data, see Use the Cloud Monitoring remote MCP server.

The Cloud Logging API MCP server is generally available (GA). To learn about using the Logging MCP server to let agents and AI applications interact with your log entries, see Use the Cloud Logging remote MCP server.

Application Monitoring in Google Cloud provides both agent observability and application observability. Your Application Monitoring dashboards display performance metrics, including the error rates and token usage of your AI resources. Those metrics can help you understand the health and performance of your AI resources.

To learn more, see the following:

• Agent observability
• Application Monitoring overview
• Investigate applications, services, and workloads
• View AI resources

Your trace data can be encrypted with a customer-managed encryption key (CMEK). To enable CMEK, set a default storage location and for that location, set a default Cloud Key Management Service key.

You can set these defaults for an organization, a folder, or a project. When set for an organization or folder, the settings apply to that resource and to its descendants. For more information, see Set defaults for observability buckets.

When you configure a default storage location, you control the location of your new observability buckets. These buckets store your trace data.

You can set a default storage location for an organization, a folder, or a project. When set for an organization or folder, the setting applies to that resource and to its descendants. For more information, see Set defaults for observability buckets.

Application Monitoring can display a single, dynamic topology map showing your App Hub applications and your registered and discovered services and workloads. This interactive map identifies services and workloads that have open incidents. It also displays the error rates and P95 latency between your services and workloads.

To learn more, see the following:

• View application topology
• Application Monitoring overview
• View application telemetry

Use Cloud Trace to troubleshoot your MCP server usage, tool failures, and latency causes. For more information, see Investigate MCP calls using Trace.

Google Cloud CLI lets you configure trace scopes, manage observability buckets, and set default observability settings. These features are in Public Preview. For more information, see the following documents:

• Configure trace scopes by using the Google Cloud console, the Google Cloud CLI, Terraform, or the Observability API. For more information, see Create and manage trace scopes.

• Manage trace storage by using the Google Cloud CLI or the Observability API. For more information, see Manage trace storage.

• Configure default settings by using the Google Cloud CLI, Terraform, or the Observability API. For more information, see Set defaults for observability buckets.

You can now ingest OTLP-formatted logs into Cloud Logging by using an OpenTelemetry Collector, an OTLP exporter, and the Telemetry API. For more information, see OTLP log ingestion overview. The Telemetry API for log ingestion is in Preview.

Cloud Logging adds support for the ca multi-region. For a complete list of supported regions, see Supported regions. This note is incorrect; see entry for June 18, 2026.

Application Monitoring has added a Services and Workloads tab, which lists your registered and discovered services and workloads. From this tab, you can do the following:

• Register discovered services and workloads.
• Search for services and workloads by functional type, such as Agent or MCP server.
• Open dashboards that display telemetry. For discovered services and workload, Google Cloud Observability uses the Cloud Asset Inventory name to identify relevant information.

To learn more, see the following:

• List registered and discovered services and workloads
• Application Monitoring overview
• View application telemetry

The filter capabilities for log views have been extended to include support for disjunctive clauses, negation statements, and labels. To learn more, see Filters for log views.

Application Monitoring has added support for the following resources:

• Vertex AI Workbench
• GKE Gateway
• GKE Ingress
• Layer 7 cross-regional Application Load Balancers

Additionally, dashboards for Kubernetes workloads display L4 and L7 traffic metrics, when both are available. For more information, see Application Monitoring supported infrastructure.

For any new project that is created on or after March 30, 2026, if the project enables the Cloud Logging API, then Google Cloud Observability also enables the Telemetry API.

For any new project that is created on or after March 30, 2026, if the project enables the Cloud Monitoring API, Telemetry API.

For any new project that is created on or after March 30, 2026, if the project enables the Cloud Trace API, then Google Cloud Observability also enables the Telemetry API.

You can use the Cloud Trace API MCP server to let agents and AI applications interact with your trace data. This feature is in Preview.

You can use the Error Reporting API MCP server to let agents and AI applications interact with your error data. This feature is in Preview.

The Telemetry API's supports up to 60,000 metric-ingestion requests per minute per region. The regional quota replaces the global quota. To learn more, see Telemetry API quotas and limits for metric ingestion.

The Telemetry API supports trace ingestion of up to 2.4GB per minute for the following regions:

• asia-east1, asia-northeast1, asia-southeast1, and asia-south1
• europe-west1, europe-west2, europe-west3, and europe-west4
• us-central1, us-east4, and us-west1.

For all other regions, the Telemetry API supports trace ingestion of up to 300 MB per minute.

These regional byte-based quotas replace a global quota which limited the number of requests per minute. To learn more, see Telemetry API limits and quotas.

Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:

• africa-south1
• asia-east1
• asia-east2
• asia-northeast2
• asia-northeast3
• asia-south1
• asia-south2
• asia-southeast2
• asia-southeast3
• australia-southeast2
• europe-north2
• europe-west1
• europe-west4
• europe-west6
• europe-west8
• me-central1
• northamerica-northeast2
• northamerica-south1
• southamerica-west1
• us-east5
• us-south1
• us-west2
• us-west3

For a list of supported locations, see Locations for observability buckets.

You can create alerting policies that monitor the results of your SQL queries. For more information, see Monitor your SQL query results with an alerting policy. This feature is in public preview.

The automatic backfill operation performed on a log bucket that has been upgraded to use Log Analytics has been temporarily paused. To manually initiate the backfill operation, contact Cloud Customer Care.

You can configure legend templates for PromQL-formatted charts. To learn more, see Configure the name of a legend column.

You can send trace data to your Google Cloud project by using the Cloud Trace API or the Telemetry API. These two APIs are enabled individually.

If you send trace data to the Telemetry API endpoint, then Google Cloud Observability requires that the Cloud Trace API be enabled on your Google Cloud project before it stores the trace data. If the Cloud Trace API is disabled, then Google Cloud Observability discards the trace data.

To learn more, see APIs that ingest trace data.

The SQL queries issued by Observability Analytics can now use a system-defined variable which resolves to the project ID. If a dashboard template uses the project ID variable, then you don't need to update the SQL query after installing the template.

For more information, see the following documents:

• Google Cloud console: Charts with SQL queries
• API: Charts with SQL queries

For organizations, folders, and projects, you can now configure default settings for observability buckets. Default settings let you specify the following for new observability buckets:

• A location.
• A Cloud KMS key.

This feature is in public preview. To learn more, see Set defaults for observability buckets.

You can now configure observability buckets to be in the following locations:

• us
• eu
• us-central1
• us-west1

Your trace data is stored in an observability bucket. To learn more, see Trace storage overview.

Starting February 18, 2026, trace sinks are deprecated. For more information, see Export trace spans with sinks deprecation.

You can use the Observability Analytics page, which provides a SQL query interface, to query both your trace and log data. To learn more, see the following documents:

• To migrate to using Observability Analytics page from a sink-based export of trace data to BigQuery, see Migrate to Observability Analytics.

• To query your trace data by using the Observability Analytics page, see Query and analyze traces.

• To query your trace data by using BigQuery services, see Query a linked BigQuery dataset.

You no longer need to configure BigQuery reservation assignments to create SQL-based alerting policies or run Log Analytics queries on BigQuery slots. These queries now use on-demand slots by default if no BigQuery reservation assignment exists.

For more information, see the following documents:

• Query a linked BigQuery dataset
• Monitor your SQL query results with an alerting policy

You can use the Cloud Logging API MCP server to let agents and AI applications interact with your log entries. This feature is in Preview.

You can use the Cloud Monitoring API MCP server to let agents and AI applications interact with your time series data. This feature is in Preview.

You can now ingest OTLP metrics into Cloud Monitoring by using an OpenTelemetry Collector, an OTLP exporter, and the Telemetry API. For more information, see OTLP metric ingestion overview. The Telemetry API for metric ingestion is in Preview.

You can now analyze your trace data by using the Log Analytics page in the Google Cloud console. This page supports SQL queries and lets you view your query results as a table or as a chart. Your SQL queries can also join your trace and log data. This feature is in Public Preview.

To learn more about analyzing and viewing trace data, see the following documents:

• Query and analyze traces
• Find and explore traces by using the Trace Explorer

Cloud Trace now stores your trace data in an observability dataset. You can continue to view your trace data by using the Trace Explorer page. If you create a link on your dataset, then you can use services like BigQuery to query and analyze your trace data. To learn more, see the following documents:

• Trace storage overview
• Manage trace storage
• Query a linked BigQuery dataset

You can now export your Crashlytics data and (optionally) Firebase sessions data to Cloud Logging. Once the data is exported, it's also available to Cloud Monitoring, so you can filter your logs, build custom dashboards, set up custom alerts, and even export the data to other services. For information about how to export your Crashlytics data, see Export Crashlytics data to Cloud Logging, and for information about how you can use this data, see What can you do with Crashlytics data in Cloud Logging.

To support correlation between log and trace data, the following changes have been made:

• The required format for the LogEntry.trace field has been relaxed. The preferred format for this field is the trace ID. However, you can continue to provide the full resource name. For more information, see LogEntry.

• If you open the Trace Details flyout page by using options provided in a log entry, then the resources listed in the default trace scope are searched for the trace data.

• If you open the Logs Explorer page by using options on span data, then the resources listed in the default log scope are searched for log data.

To learn more about default scopes, see Configure observability scopes for multi-project queries.

You can now install and manage the Ops Agent on virtual machines across zones in your Google Cloud project by using global VM Extension Manager extension policies. Global and zonal extension policies can keep the installed version of the agent current, keep a specified version of the agent installed, and other tasks. For more information, see Install and manage the Ops Agent by using VM Extension Manager policies.

You can now install and manage the Ops Agent on virtual machines across zones in your Google Cloud project by using global VM Extension Manager extension policies. Global and zonal extension policies can keep the installed version of the agent current, keep a specified version of the agent installed, and other tasks. For more information, see Install and manage the Ops Agent by using VM Extension Manager policies.

To support correlation between log and trace data, the following changes have been made:

• The required format for the LogEntry.trace field has been relaxed. The preferred format for this field is the trace ID. However, you can continue to provide the full resource name. For more information, see LogEntry.

• If you open the Trace Details flyout page by using options provided in a log entry, then the resources listed in the default trace scope are searched for the trace data.

• If you open the Logs Explorer page by using options on span data, then the resources listed in the default log scope are searched for log data.

To learn more about default scopes, see Configure observability scopes for multi-project queries.

Your Application Monitoring dashboards now display the trace spans that are associated with your registered App Hub applications. The display includes annotations that let you identify services and workloads. You can also open the Trace Explorer page from your Application Monitoring dashboards. To learn more, see the following documents:

• Application Monitoring overview.
• View application telemetry.
• Find and explore traces describes how to use the Trace Explorer page to filter and explore your trace data.

Cloud Logging adds support for the asia-southeast3 region. For a complete list of supported regions, see Supported regions.

You can now collect, view, and analyze multimodal prompts and responses from your agentic applications that use the LangGraph or Agent Development Kit (ADK) frameworks. This feature is in Public Preview.

To learn more, see the following documents:

• Collect and view multimodal prompts and responses
• Instrument generative AI applications