Cloudflare brings logs, traces and analytics into one observability platform
Cloudflare announced eight Observability updates covering logs, traces, analytics, alerts, dashboards, querying and telemetry export. This is an operational visibility change, not an automatic incident-fixing tool. Its practical promise is fewer separate screens, APIs and pricing models when a team investigates an issue crossing the edge, Workers and an origin.
What is changing
A 5xx spike can originate in a Worker, an origin, or edge-to-origin connectivity. Cloudflare’s new Logs home combines Workers Observability and Log Explorer. Teams can select HTTP events, firewall events, Workers, Containers, R2 or AI Gateway datasets; filter and group by hostname or data center; inspect a request by Ray ID; then switch datasets. Cross-dataset querying is described as forthcoming.
Eight specific updates
- Unified Logs home for several log datasets and investigation tools.
- Cloudflare Traces open beta with request-level views, sampling, Trace Rules and Ray ID search.
- Unified SQL API beta with one SQL dialect, authentication model and API for telemetry data.
- New observability pricing based on ingest and storage volume from December 1, 2026.
- Custom Alerts beta using SQL, thresholds, anomalies or SLOs.
- Thirty days of domain analytics on every plan.
- Custom Dashboards for metrics, logs, traces and security events.
- Logpush on self-serve plans, plus SQL Transformers and usage-based charges.
Why this needs careful evaluation
A unified platform is not automatically a single safe dataset or access model. Traces can contain sensitive URL, header or attribute data. Low sampling can miss an incident; high sampling during investigation can sharply raise data volume. SQL APIs, CLIs and webhooks enable automation, but need least privilege, auditing, credential control and clear limits on what an agent may read.
The pricing change also requires measurement. The announcement moves toward GB ingested and stored rather than event counts. Teams should model baseline and peak traffic, retention, traces, external exports and storage before deciding whether their total cost changes.
Practical checklist
- Inventory datasets, owners, retention and sensitive fields before enabling traces or export.
- Set baseline sampling, short-lived investigation rules and a volume budget.
- Build dashboards around actionable SLI signals: 5xx, latency, cache/origin health and Worker errors.
- Test alerts with synthetic events; define routing, ownership and anti-fatigue rules.
- Apply least privilege to SQL API, CLI, Logpush and webhooks; rotate credentials.
- Compare current spend against expected ingest, storage, retention and egress before the pricing date.
Conclusion
The update matters for organisations using multiple Cloudflare products because it follows the actual incident-investigation path more closely. Start with one service, one dashboard and a small owned alert set, then expand traces, SQL and exports after data and cost controls are proven.
How to turn the updates into useful operations
Observability works when a signal leads to a named decision. For example, a latency dashboard should show the service owner whether the next step is checking cache behaviour, a Worker deployment, an origin region or a security rule. A trace is most useful when its sampling and retention match that decision. Teams should define which headers and attributes are allowed into telemetry, mask identifiers before export, and periodically review whether dashboards are still read during incidents.
Automation also needs a safety boundary. A webhook can open a ticket or gather evidence, but it should not automatically change routing, firewall policy or production code merely because a threshold fires. Store query definitions with change review, test them against known incidents, and make alert messages include the affected scope and a runbook link. This keeps the new shared interface from becoming another high-volume source of unactionable notifications.
Source
Cloudflare Blog: 8 major updates to Cloudflare Observability