--- title: "Worker observability" --- > Documentation Index > Fetch the complete documentation index at: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/llms.txt > Use this file to discover all available pages before exploring further. # Worker observability 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](/build/worker-security/) 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](/operations/observability/). Organization limits are described in [Usage and quotas](/build/usage-and-limits/). Source: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/build/observability/index.mdx