One place for every Worker's telemetry
Workers Observability is now available in the Cloudflare Dashboard as a dedicated section for querying log events across all Workers in an account. The new surface combines a metrics dashboard, a query tool, and the now generally available Workers Logs into a single workflow, replacing the previous per-Worker view of logs and metrics.
Three components make up the release:
- Workers Metrics Dashboard (Beta): account-level visibility into metrics and logs from every Worker.
- Query Builder (Beta): structured queries over logs, including metric extraction, visualizations, and saved queries.
- Workers Logs: generally available with a public API and invocation-based log grouping.
Query Builder
The Query Builder in the Observability tab answers "why" questions about your Workers. It supports structured queries against log data, such as finding the p90 wall time for 200 OK responses from the /reference endpoint — in this case, a 6 millisecond result.
A query is composed of several building blocks:
- Visualizations: aggregate functions like average, count, percentile, or unique that reduce a group of values to one result, shown as both graph and table.
- Filters: conditions that exclude data not matching criteria.
- Search: a string match that returns only matching data.
- Group by: collapses a field to distinct values so aggregates can be applied granularly.
- Order by: sorts returned rows.
- Limits: caps the number of rows returned.
The Query Builder depends on structured logs, which store context-rich metadata as key-value fields with high dimensionality and high cardinality. Invocation Logs serve as an example, capturing network-level insights from Cloudflare. Logging metadata as structured data allows queries that weren’t anticipated when writing the code.
Internally, the Workers Observability team used the builder to find a bug in its staging environment. A query on events per script revealed a drop, which was mapped to a recent deployment and root-caused. New staging alerts were added to catch similar regressions.
Queries built in the builder or Workers Logs can be saved with custom names and descriptions, starred, and shared via a link — simplifying collaborative debugging and visualization work.
CPU time and wall time
CPU time and wall time are now available for every invocation across Tail Workers, Workers Logpush, and Workers Logs. These metrics separate code execution time from total elapsed time, including I/O. Invocation Logs surface both values, and the Query Builder can render them as p90 traffic views for a single script.
Metrics overview and invocations
The Observability tab now includes a Workers Metrics overview page that supports comparing metrics across Workers and reviewing deployment state from one screen. This follows February’s per-Worker metrics improvements for gradual deployments.
Workers also gain an Invocations View. Previously, logs were shown as a flat event stream. Now, logs are grouped by invocation — the event that triggered the Worker or Durable Object, such as a fetch, alarm, or cron job. The view is available from each Worker’s page and in the Workers Observability tab.
API access
Telemetry data can be retrieved programmatically via the Workers Observability API. This supports automations, custom integrations, notebook analysis, and correlation with logs from other systems. The API complements the dashboard for workflows that need more flexibility or repetition.
Getting started
To use Workers Logs, enable the setting in your Worker’s configuration in the dashboard or add the configuration to the Wrangler file.
Feedback and feature requests are being collected in the #workers-observability channel on Discord.



