Script exceeded CPU time limit error with crypto.subtle and compatibility_date

Answer to the core question

For most crypto.subtle workloads that run on the free tier, setting compatibility_date to 2023‑09‑01 or later provides consistent compliance with the per‑request CPU limit. Workloads that rely on the older isolate (any date before 2023‑09‑01) frequently exceed the limit because the Web Crypto implementation is less efficient.

Why the date matters

Cloudflare Workers use a V8 isolate that changes with the compatibility date. The isolate introduced on 2023‑09‑01 includes an optimized native Web Crypto backend that reduces the CPU cycles required for operations such as RSA key generation, ECDH, and AES‑GCM. The pre‑2023‑09‑01 isolate implements these algorithms in software or via a less‑efficient bridge, which can consume several hundred milliseconds of CPU time for a single operation.

Interaction with third‑party polyfills

Libraries that polyfill Node.js’ crypto module (for example crypto‑js or node‑crypto‑polyfill) do not use the native crypto.subtle API even when the newer isolate is available. They re‑implement the algorithms in JavaScript, which still incurs the same high CPU cost as the old isolate. Consequently, a worker that uses such a polyfill can hit the limit regardless of the compatibility_date setting.

Observable differences between runtimes

• Pre‑2023‑09‑01: slower crypto operations, higher CPU usage, frequent "Script exceeded CPU time limit" errors on the free tier.
• 2023‑09‑01+: faster operations, lower CPU usage, fewer limit breaches. Heavy workloads (large‑key RSA or long‑running hash chains) may still approach the limit.
• Polyfill usage: performance is largely unchanged across both isolates because the work is performed in JavaScript, not native Web Crypto.

Practical steps for your worker

1. In wrangler.toml, set compatibility_date = "2023‑09‑01" (or a later date).
2. Audit the code base for any imports that pull in a Node.js crypto polyfill. Replace them with direct crypto.subtle calls where possible.
3. Deploy the updated worker to production and monitor the "CPU time" metric in the Cloudflare dashboard. The free tier allows up to 50 ms per request; a consistent stay below this threshold indicates compliance.
4. If the worker still exceeds the limit, identify the specific operation (e.g., RSA key generation, SHA‑512 hashing) that consumes the most CPU.

Because the new isolate is not a silver bullet for all workloads, the most reliable way to avoid the error is to keep the total CPU per request well under the free‑tier threshold and to avoid heavy JavaScript polyfills for cryptographic work.

Missing diagnostic detail

Could you specify which third‑party library (if any) you are using for cryptographic operations? Knowing that would help refine the recommendation.