Cloudflare moves logs, traces and Logpush exports onto one observability platform

Cloudflare's own worked example is a spike in 5xx responses. The post says it could come from a Worker, from the origin, or from Cloudflare failing to connect to the origin, and that investigating it today means knowing which product owns each signal ^[6]. The Logs home lists HTTP events, firewall events, Workers, Containers, R2 and AI Gateway as datasets under the same tools ^[4]. Queries run as raw SQL or built-in filters, and you can switch datasets without leaving the page ^[17]. Correlating those datasets is still manual, because a single query across them is listed as coming soon ^[5].

The sampling design in Traces is the best engineering in the release ^[8]. It has two tiers. A baseline rate runs all the time, and Trace Rules capture chosen hostnames, paths, IP addresses or headers at a higher rate during an investigation ^[8]. Volume stays low until someone is looking, and the suspect traffic gets denser coverage while they are. Individual requests can be found by Ray ID and inspected as spans in the dashboard ^[8].

The SQL API replaces separate integrations for Workers logs, Containers security events, HTTP request logs and analytics data with one SQL dialect, one authentication model and one API ^[10]. Cloudflare publishes dataset schemas, fields and example queries to help people and agents write those queries ^[18]. A native binding brings the same SQL interface inside Workers, so a Worker can query Analytics Engine data directly ^[12].

Cloudflare says more products, datasets and workflows will join the platform over the coming months ^[14]. It wrote that these eight updates are "the first step into a more unified Observability problem" ^[15]. I assume the last word was meant to be platform.

For a team already shipping Cloudflare logs to its own store, the release splits that pipeline into two jobs. Day-to-day triage can move into the Logs home. A long-term archive can stay external, fed by Logpush ^[3]. The launch list describes one pricing model for data ingested and stored across Cloudflare, and the list does not state a rate ^[2]. Comparing the two options needs that rate, the team's monthly ingest volume, and what its current pipeline costs per gigabyte. In my view, a team that depends on joining firewall events with application logs should keep its external pipeline until cross-dataset queries ship ^[5].