Use your organization’s console to understand application usage and investigate failures. Its telemetry is scoped to your organization and Worker permissions.
Choose the right view
Open a Worker in the console and select Observability. The page provides five focused views instead of mixing every signal into one dashboard:
- Usage summarizes total invocations, failures, background activity, and invocation rate by activation path. This is the closest view of allowance consumption because every supported activation counts as one Worker invocation.
- HTTP shows ingress rate by exact response status and p50/p95/p99 response duration.
- Background shows queue, scheduled, alarm, and custom activations plus queue-handler duration.
- Capacity shows shared runtime-pool CPU and memory for diagnosing platform pressure. It is not per-Worker usage or billing attribution.
- Logs keeps application events and their filters together, with a bounded scroll area and live/pause controls.
Deployment markers remain on the relevant charts. Observability is separate from Worker overview and version detail so traffic history is not confused with an individual deployment artifact.
Time range and version filters apply where the selected view supports them. Invocation type selects runtime activity, while HTTP status and method select ingress traffic. Level and text search are local to Logs. The selected view and all filter state are represented in the URL, so an investigation survives refresh and can be shared or bookmarked.
Use Live to stream recent application logs, then Pause to freeze the view. Resuming catches up from the saved cursor where possible. Live delivery is best effort: it polls stored records every two seconds, limits streams and history, and explicitly indicates gaps. It is not an audit log.
The console authorizes every telemetry request with the current organization’s
workers.read access and Worker scope. One tenant cannot query another
tenant’s traffic, logs, or version history.
What the charts mean
Request counts and durations come from HAProxy completion records collected by
Alloy into Loki. Response duration is HAProxy total active time (Ta) in
milliseconds: it includes Worker execution and response transfer through the
proxy, but not client DNS/TCP setup or a direct Worker CPU measurement.
Request-rate charts draw a zero for known idle intervals. Duration percentiles remain empty when there are no requests, because zero is not a duration sample. Charts show a degraded state when collection health, freshness, or parsing signals fail. Healthy collection is not a guarantee of lossless delivery and these values are not billing counters.
Ingress protection decisions live under the Worker’s Security tab. Requests blocked there never reach application code and are excluded from application request charts and logs. Observe-mode requests that reach the Worker remain ordinary application traffic.
The runtime tail consumer records every invocation’s event type, outcome, queue name, and batch size. That gives queue consumers and other background-only Workers invocation-rate and outcome views without pretending that a queue event is an HTTP request. Queue handler duration is measured independently by the queue service around the complete consumer call, including Worker code and its bindings. Queue histograms are not labeled by deployment version, so the console does not display them while a version filter is active.
The standalone workerd server currently emits zero for legacy tail CPU and
wall-time fields, so the console deliberately does not present those values as
Worker usage. CPU and memory charts show the whole shared runtime pool as
capacity context. Neither can be honestly attributed to a tenant Worker or used
as a quota counter yet.
Application console.* output and uncaught exceptions are exported by a
platform-owned workerd tail consumer after an invocation completes. Messages
may therefore arrive after the response, especially for waitUntil() work.
Application text is untrusted, bounded, and rendered as text; applications
remain responsible for not logging secrets.
Stateful and scheduled work
Stateful Workers add a Durable Objects detail tab with member placement, namespace identity, observed object files and storage bytes, plus deployment, recovery, and restart history. These values describe state ownership and lifecycle, not per-object CPU or memory reservations.
Compute → Durable Objects provides that context across the organization. Compute → Schedules shows trigger state and last delivery outcomes, with links into each Worker’s scheduled invocations and logs. Pausing a schedule stops new delivery, not telemetry collection.
Images usage and activity
Media → Images shows organization-scoped operation rate, sampled p95 duration, and recent transformations. These views query structured Images operation logs, not the service’s fleet-wide Prometheus counters. Duration covers the service operation including input and response transfer. Rejections and quota enforcement are visible without being described as platform outages.
The Workers tab lists current bindings, while Activity retains a bounded, paginated view of the latest 200 operations in the selected time window. The monthly quota ledger remains the authoritative usage count; retained telemetry is diagnostic evidence and can cover a different interval. For platform health and service measurements, operators use Platform observability. Organization limits are described in Usage and quotas.