Today, we’re launching eight major updates that bring your logs, traces, analytics, alerts, dashboards, and exporting into one observability platform , with simpler and more predictable pricing. Here's what's launching: One place to explore logs from across Cloudflare End-to-end tracing from Cloudflare's edge to your origin One unified SQL API for querying Cloudflare data One pricing model for observability data ingested and stored across Cloudflare Custom alerts on your observability data All analytics for your domain in one place, with 30 days of data retention Custom dashboards built from your observability data Export your data with Logpush -- now available on self-serve plans One observability platform for all of Cloudflare Understanding an issue often requires data from more than one Cloudflare product.
A spike in 5xx responses could come from a Worker, from your origin, or from Cloudflare failing to connect to your origin globally or regionally. But investigating it today requires knowing which product owns each signal and how to query it. Observability should be a platform-wide capability: it should reflect how applications actually behave and give you the complete context needed to resolve an issue.
Over the coming months, you’ll see more Cloudflare products, datasets, and workflows become part of this shared observability platform, with more consistent pricing, product experiences, and features. These eight updates are the first step into a more unified Observability problem. 1.
Investigate all your logs in one place The new Logs home combines Workers Observability (for debugging Workers applications and its connected resources) with Log Explorer (for searching across security logs). You can now choose from log datasets like HTTP events, firewall events, Workers, Containers, R2, and AI Gateway, and use the same investigative tools and capabilities for each.
Start with an increase in request latency, group it by hostname or data center, narrow the results to affected paths, and inspect individual requests by Ray ID. If the investigation leads to another Cloudflare product, switch datasets without leaving Logs. Support for querying across multiple datasets is coming soon, making it possible to connect related events across products in a single query.
You can query your logs with raw SQL or with built-in filters to narrow down on specific events. Create visualizations with natural language, and easily investigate and understand detected anomalies. Copy prompt Use cf cli (https://developers.
cloudflare. com/cf/) to query my Worker logs/traces using the sql API and tell me about any unusual patterns or trends. If there is nothing unusual, give me a rundown of the past few days of my traffic.
If I am not logged in bring me through the auth flow. 2. Trace requests through our entire platform — now in open beta We’re launching Cloudflare Traces in open beta , giving you a request-level view of supported security rules, transformations, cache decisions, routing, Workers, and origin handling.
You get to see how your traffic moved through our platform, and connect the dots between how you’ve configured Cloudflare, and how this influences request processing time, routing decisions, and more. Set a baseline sampling rate for continuous visibility, then use Trace Rules to capture specific traffic at a higher rate during an investigation. Target hostnames, paths, IP addresses, or headers, search by Ray ID , and inspect the resulting spans directly in the Cloudflare dashboard.
You can export traces over OpenTelemetry , while W3C trace context propagation lets you accept incoming trace context and pass along context to your origin. Check out the full blog post to learn more about Cloudflare Tracing or give this command to your agent to get started: Copy prompt Using the Cloudflare cf CLI, configure Tracing for my zone with a 10% sampling rate and persist traces in Cloudflare.
If I have multiple zones, ask me which one to use. 3. Have your agent query observability data with one unified SQL API Agents also need a consistent way to sift through your observability data, investigate issues, correlate signals, and verify fixes.
We’re launching a unified SQL API, now in beta, for querying telemetry across Cloudflare. Instead of integrating separately with Workers logs, Containers security events, HTTP request logs, and analytics data, people and agents can query them using one SQL dialect, authentication model, and API. Your agent can use the new Cloudflare CLI , cf , to find and run queries from the command line or connect through Cloudflare’s Observability MCP server to investigate logs, traces and analytics.
Dataset schemas, fields, and example queries are available to help both people and agents build queries. Additionally, we’re also bringing the SQL interface directly into Workers with a native binding. Your Worker can now do things like query Analytics Engine data to meter customer usage and power billing workflows, build customer-facing analytics dashboards, generate health reports, or automate incident investigation without configuring a separate API client.
- New pricing for all ingested and stored logs and traces For all logs and traces ingested and stored on Cloudflare, we are moving to one unified Observability subscription and pricing. Beginning December 1, 2026 , this pricing model will apply across all plans (effective upon renewal for all Enterprise customers) and cover existing Developer Platform logs, including Workers, Containers, AI Gateway, as well as all tracing data.
Because logs and traces can vary dramatically in size, the new model is based on the volume you ingest and store rather than an event-based count. This pricing adjustment will be. Check out our documentation for more details on pricing.
Plan Included Usage Retention Additional usage Free 0.
Originally published at blog.cloudflare.com
