Workers metrics show performance and usage of your Workers and help diagnose issues and are available in Zone and Worker script contexts.
Aggregates request data for an individual Worker script across all zones including your workers.dev subdomain. On your Workers dashboard, click on any Worker to view its metrics.
Worker script metrics can be inspected for up to 3 months in the past in maximum increments of 1 week. The dashboard includes the charts and information described below.
Worker invocation statuses indicate whether a Worker script executed successfully or failed to generate a response in the Workers runtime. Invocation statuses differ from HTTP status codes. In some cases, a Worker script invocation succeeds but does not generate a successful HTTP status because of another error encountered outside of the Workers runtime. Some invocation statuses result in a Workers error code being returned to the client.
|Invocation status||Definition||Workers Error code||GraphQL field|
|Success||Worker script executed successfully|
|Client Disconnected||HTTP client (i.e. the browser) disconnected before the request completed|
|¹ Exceeded Resources||Worker script exceeded runtime limits||1102, 1027|
|² Internal Error||Workers runtime encountered an error|
¹ The Exceeded Resources status may appear when the Worker exceeds a runtime limit. The most common cause is excessive CPU time, but is also caused by a script exceeding startup time or free tier limits.
² The Internal Error status may appear when the Workers runtime fails to process a request due to an internal failure in our system. These errors are not caused by any issue with the Worker code nor any resource limit. While requests with Internal Error status are rare, we expect that some may appear during normal operation. These requests are not counted towards usage for billing purposes. If you notice an elevated rate of requests with Internal Error status, please check www.cloudflarestatus.com.
This chart shows historical request counts from the Workers runtime broken down into successful requests, errored requests, and subrequests.
fetchfrom within a Worker script. A subrequest that throws an uncaught error will not be counted.
Request traffic data may display a "drop off" near the last few minutes displayed in the graph for time ranges less than six hours. This does not reflect a drop in traffic, but a slight delay in aggregation and metrics delivery.
The CPU time chart shows historical CPU time data broken down into relevant quantiles using reservoir sampling. You can learn more about interpreting quantiles here. In some cases, higher quantiles may appear to exceed CPU time limits without generating invocation errors because of a mechanism in the Workers runtime that allows rollover CPU time for requests below the CPU limit.
Zone data can be scoped by time range within the last 30 days. The dashboard includes charts and information described below.
This chart shows subrequests - requests triggered by calling
fetch from within a Worker script - broken down by cache status.
This chart shows historical bandwidth usage for all scripts on a zone broken down by cache status.
This chart shows historical requests for all scripts on a zone broken down by HTTP status code.
This chart shows historical data for all scripts on a zone broken down by successful requests, failed requests, and subrequests. These request types are categorized by HTTP status code where 200-level requests are successful and 400 to 500-level requests are failed.
Worker script metrics are powered by GraphQL. Learn more about querying our data sets in this tutorial.