Server
Worker
Also called Cloudflare Worker.
Worker is a small program that runs on a provider's network in response to a request, without you managing a server. On Cloudflare it executes in an isolate near the visitor.
How it is measured
Look at the dashboard and logs for requests, errors, CPU time per request and subrequests. CPU time is the figure the platform limits, often 10 to 50 ms on standard plans, and wall time includes waiting on fetches.
Deploy-level checks: the route or hostname it is bound to, the bindings it uses (KV, D1, R2), and the version currently live.
Worked example
A Worker sits in front of a WordPress origin and adds security headers, redirects /old-shop/* to /shop/*, and serves a cached copy of /pricing for 10 minutes. About 1.6 million requests a month run through it, with a median CPU time of 1.1 ms.
The origin sees 31 percent fewer hits. A coding mistake that parsed a 4 MB JSON body inside the Worker pushed CPU to 60 ms and triggered limit errors until the parse was moved to the origin.
How it differs
A worker is the program deployed on the platform. An isolate is the sandbox that runs it. An edge function is the broader category of code that runs near the visitor. Worker excludes the origin app and the underlying engine, isolate excludes your code. Edge function is a generic description, worker is one product's word for it.
Common errors
Doing heavy CPU work inside the per-request limit. Treating global variables as durable storage. Making many subrequests to a distant origin. Forgetting a Worker route can intercept requests you thought bypassed it. Deploying without a rollback version.
In practice
Start with one small job such as a redirect, header rule or cached response, watch CPU time and error count for a week, and keep the origin able to serve everything if the Worker is disabled.