Cloudflare brings Worker logs and traces into custom dashboards

Application and network signals share a view

Cloudflare’s October 2 changelog introduces Workers Observability Logs and Workers Observability Traces datasets in Custom Dashboards. Operators can chart invocations, errors, log levels, CPU time, wall time, spans and durations alongside network traffic and security analytics. The data is available for Workers with the corresponding logging or tracing enabled. The same update raises the custom-dashboard allowance to 100 per account.

This is distinct from simply collecting more telemetry. It gives an operator a common place to compare signals that describe different parts of the same request path. An increase in application errors can be examined alongside an edge traffic change or a security-rule adjustment without manually switching between unrelated views. That reduces friction in the first minutes of an incident, when establishing the sequence of events is often the most important work.

Source: Cloudflare official changelog

Analysis: Correlation needs a shared interpretation

Putting charts together can reveal useful coincidences, but a coincidence is not a root cause. A traffic surge might increase errors, or both could follow an unrelated deployment. Different collection delays can also make one event appear to precede another. Dashboard owners should use compatible time ranges and document whether each series describes all requests, sampled events or only the subset reaching an application.

CPU and wall time deserve separate interpretation. A Worker waiting for another service may have low CPU consumption and high elapsed duration; optimizing local code would then address the wrong bottleneck. Traces can help locate that wait, while an error-rate chart shows the customer-facing effect. The dashboard should support a decision about the next evidence to collect, rather than imply that a single metric explains the whole system.

Build a view around an operational decision

Begin with the service’s most consequential failure mode. For a checkout endpoint, show successful transactions, errors, dependency durations and relevant edge controls. For an internal API, emphasize access failures, latency and upstream health. A dashboard with dozens of unrelated panels can increase search time and make the important exception harder to see. The expanded allowance is useful for service ownership, not an invitation to multiply views without purpose.

Check that logging is enabled on the Worker the team expects to investigate and that sensitive fields are handled appropriately. Link each chart to the query or trace view needed for follow-up, and give the dashboard a named owner. Review it after an actual incident to see which panels influenced the response. The value of unified observability is measured by faster, better-supported operational decisions. Shared presentation helps, but clear signal definitions and an accountable response process are what make the presentation reliable.