Cloudflare’s single observability platform shortens cross‑product troubleshooting

Cloudflare’s update collapses multiple observability signals into a single place, cutting the time your team spends stitching logs and traces and changing where you will measure ingestion and storage costs.

What actually changed

Cloudflare combined logs, traces, analytics, alerts, dashboards and export functions into a single observability product. The launch lists eight specific capabilities: a single place to explore logs across Cloudflare; end-to-end tracing from Cloudflare’s edge to your origin; a unified SQL API to query Cloudflare data; "one pricing model" for observability data ingested and stored across Cloudflare; custom alerts; centralised analytics for your domain with 30 days of retention; custom dashboards built from observability data; and Logpush exports now available on self‑serve plans.

Each item is an integration point: logs and traces can be queried together via the new SQL API; dashboards and custom alerts can be built from that same data; and exports via Logpush can move data off‑platform if you still need a separate storage or BI system.

Who it affects

• Small teams that host services behind Cloudflare and currently query different Cloudflare products separately (for example Workers and origin servers) to diagnose incidents.
• Teams that rely on domain analytics for operational visibility; Cloudflare now keeps analytics in one place for 30 days.
• Any organisation using Logpush who wants to export observability data from self‑serve accounts rather than using an enterprise integration.

The announcement speaks directly to the problem of cross‑product investigation: a spike in 5xx responses “could come from a Worker, from your origin, or from Cloudflare failing to connect to your origin,” and the new platform aims to remove the need to know which product owns each signal before you start querying.

What it costs or what it replaces

Cloudflare says observability will move to a simpler and more predictable pricing structure and that there will be "one pricing model for observability data ingested and stored across Cloudflare." The announcement does not state pricing rates, tier thresholds, free allowances, or whether existing customers will be grandfathered under current billing arrangements.

Functionally, the platform replaces the current workflow where teams must query individual Cloudflare products separately and then stitch results together. It also changes the export story by making Logpush available on self‑serve plans, reducing the need to upgrade to an enterprise plan solely for export capability.

What we don't know

• Precise pricing: per‑GB ingestion, storage rates, or tier thresholds are not stated.
• Billing changes for existing customers: whether usage will be migrated automatically, or whether there are transition windows.
• Retention beyond the stated 30 days for domain analytics: longer retention terms and costs are unspecified.
• Rate limits, quotas or query performance guarantees for the unified SQL API.
• Rollout and availability by account type or region, and whether feature parity exists across all Cloudflare products.
• Any additional egress or export charges when using Logpush from self‑serve plans.

What to do next

1. Inventory your signals this week: list which Cloudflare products you use (for example Workers and your origin), which logs and traces you currently pull, and how much data you ingest and store now. Record current monthly ingestion and storage volumes so you can compare against Cloudflare’s new pricing when it is published.

1. Test exports and alerts: if you rely on Logpush, try exporting a representative sample on your self‑serve plan to confirm format, latency and any manual steps required. Also identify two high‑priority alerts you rely on and map how they would be rebuilt using the unified SQL API and custom alerts.

1. Ask Cloudflare for specifics: contact your account rep or check the official announcement for published pricing, migration guidance, quotas and availability dates; do not assume cost parity until you have the published rates.