Cloudflare Workers Error 1102: Find CPU or Memory Limit First

Separate CPU time from memory#

Cloudflare’s current Workers limits list a 128 MB per-isolate memory limit. They also document CPU limits by plan, including 10 ms per HTTP request on the Free plan and a higher configurable limit on paid plans. Treat those numbers as platform settings to verify on the day of deployment, not constants to copy into application logic.

Read the invocation that returned 1102#

Preserve the request path, deployment version, timestamp, status, and resource information from Workers Logs. The Workers errors and exceptions reference maps 1102 to exceeded CPU time and distinguishes it from other runtime errors.

Use a minimal reproduction with a known input size:

1
request size -> route -> CPU time -> memory behavior -> response

Compare a small and a large input, then compare the route with expensive work disabled. The goal is to find whether the failure threshold follows input size, synchronous computation, or accumulated state. A single successful request does not prove that the route stays below the limit for the production payload.

For local profiling, run the Worker through the same development or build path that production uses and inspect the expensive synchronous section. Cloudflare recommends DevTools CPU profiling for CPU-heavy code and memory snapshots for allocation problems. Add temporary timing around parsing, transformation, and serialization rather than measuring only the whole request.

Reduce CPU-bound work#

When the logs point to CPU time, start with code that runs before and after network calls:

• avoid repeated parsing or serialization of the same payload;
• replace nested scans with an indexed lookup where the data shape allows it;
• process a large collection in bounded batches instead of one synchronous loop;
• cache stable computed results outside the hot path when the cache semantics are safe;
• move long-running work to a queue, Workflow, or another execution boundary when one request should not own it.

Waiting for network I/O is not the same as spending CPU. Cloudflare’s performance documentation explains how to measure CPU-intensive sections and notes that subrequest time is not CPU time. Optimize the synchronous work around fetch(), not just the number of upstream calls.

If the workload is genuinely CPU-bound and fits the platform’s request model, a paid CPU-time setting may be appropriate. Verify the configured limit and retest the same route; do not use a plan change to hide an unbounded loop or a request that should be processed asynchronously.

Reduce memory pressure#

When the failure follows payload size or concurrent requests, look for buffering first:

1
// Risky for unbounded input
2
const text = await request.text();
3
const data = JSON.parse(text);
4

5
// Prefer a bounded contract or streaming path for large input.
6
const MAX_BYTES = 10 * 1024 * 1024; // example application limit
7
const contentLength = Number(request.headers.get('content-length') || 0);
8
if (contentLength > MAX_BYTES) {
9
  return new Response('Payload too large', { status: 413 });
10
}

The example is an application guard, not a replacement for Cloudflare’s edge limits. For large bodies, avoid keeping the full request and transformed result in memory at the same time. Use a ReadableStream or TransformStream when the format supports incremental processing, and avoid accumulating every item in a global array.

If the request is rejected before the Worker runs, that is a request-size problem rather than a 1102 memory failure. The Cloudflare Workers 413 guide covers the edge, zone, and origin boundaries separately.

Verify the fix with a boundary matrix#

Run the route against inputs that are just below and above the suspected threshold:

After deployment, watch the same route and version in Workers Logs. A 1102 count that falls after a code change is useful evidence, but it does not replace checking tail latency, input limits, and error handling for the next larger payload.

The practical takeaway is to classify error 1102 before changing the code or plan. CPU needs less synchronous work or a deliberate CPU budget; memory needs bounded data flow and less buffering. The log and a small reproducible input tell you which path you are actually on.

FAQ#