Python Workers Free: minimal responses sometimes exceed the published 10 ms CPU allowance

[grimbouk]

Reproduction

Observed 9 October 2026 on Workers Free, compatibility date 2026-10-09, flag python_workers, Wrangler 4.149.0, workers-py 1.17.7, workers-runtime-sdk 1.9.3.

Minimal Python entrypoint, with no Flask import or database access:

import js
from workers import WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return js.Response.new("Python runtime control")

After deployment, six sequential requests returned 200 with outcome: ok. Top-level cpuTime from wrangler tail --format json was 9, 22, 10, 17, 8 and 20 ms. These are a small sample, not percentile statistics. No exceededCpu error was observed.

A small Flask application using the supported WSGI adapter showed much larger and variable CPU use, including repeated requests. Passing a native Request into the adapter and testing bounded buffered WSGI replies did not consistently bring requests below 10 ms. Local Worker profiling showed substantially smaller warm Flask timings. Deployed cProfile function timings were zero, consistent with frozen deployed timers, so those profiler values were not used as CPU evidence.

Questions

1. Does Python cpuTime include runtime/snapshot initialization or other overhead treated differently by the Free enforcement limit? How should cold and warm Python requests be assessed against the published allowance?
2. Is there a supported Python runtime/SDK configuration or profiling method to identify and reduce this overhead on Free?
3. Can a Flask application be considered reliable on Free when a minimal Python control sometimes exceeds 10 ms, despite successful responses? We do not want to rely on occasional-overrun flexibility.

References: CPU limits, Python deployment lifecycle, deployed timers.

No account identifier, deployment URL, credential, user email, private repository or application dataset is needed for this reproduction.

[dfbustosus]

Short answers from the published limits docs, then the practical read of your measurements:

1. What cpuTime includes. CPU time is defined as time the CPU spends executing your Worker code — waiting on I/O doesn't count. The docs don't break accounting down further (no published split between your entrypoint and runtime work performed on its behalf), but for Python Workers the interpreter executing your module during a request is your code as far as the meter is concerned. Isolate startup is governed by the separate 1-second startup limit, so init attributed to a request's isolate — which is what you'd expect on a cold isolate — shows up in per-request CPU on the requests that pay it.

2. Why you see 8–22 ms with outcome: ok on a 10 ms Free limit. This part is documented and matches your data exactly: "Each isolate has some built-in flexibility to allow for cases where your Worker infrequently runs over the configured limit. If your Worker starts hitting the limit consistently, its execution will be terminated." So the 10 ms Free allowance is a consistency-enforced budget, not a hard per-request cutoff: occasional overruns return 200 silently, and only sustained exceedance produces Error 1102 / exceededCpu. Your six samples straddling 10 ms with no exceededCpu is precisely the tolerated regime — nothing is wrong with your deployment. (For calibration, the docs put the average Worker at ~2.2 ms and note that heavier workloads "typically" land at 10–20 ms — i.e., above the Free line.)

3. The Flask part. The WSGI adapter realistically can't get a warm Flask app under 10 ms per request — your local profiling showing smaller warm times is consistent with deployed requests paying isolate placement and interpreter warm-up that local runs don't. On Free, the sustainable Python envelope is essentially the trivial-handler shape you already measured (~8–10 ms warm); anything stateful like Flask is sized for Workers Paid (default 30 s, adjustable to 5 min via limits.cpu_ms). If you must stay on Free: keep the handler allocation-free, return pre-constructed responses, and accept that tail requests will occasionally sit in the tolerated-overrun band rather than erroring.

One measurement note since you were careful about methodology: wrangler tail --format json cpuTime is the same field Workers Logs/Logpush report, so your numbers are the authoritative per-invocation accounting — no separate "billable CPU" view exists that would tell a different story.