El límite de tiempo de CPU

Quien llega desde un servidor tradicional trae grabada una intuición: si mi petición tarda treinta segundos, es que consumí treinta segundos de máquina. En Workers esa intuición es falsa y hay que desaprenderla. El límite que impone la plataforma no mide el tiempo que pasa desde que entra la petición hasta que sale la respuesta, sino solo los instantes en que el procesador está de verdad ejecutando tu código. Todo el tiempo que tu Worker pasa esperando la red es gratis y no cuenta. Entender esa distinción es entender el modelo de coste entero.

Qué cuenta como CPU y qué no

El CPU time es el tiempo que el procesador pasa ejecutando instrucciones de tu código: parsear JSON, recorrer un array, comprimir un buffer, calcular un hash, renderizar HTML. El tiempo de reloj de pared, en cambio, es el que mide un cronómetro colgado en la pared desde que llega la petición hasta que se va la respuesta, esperas incluidas.

La diferencia entre ambos es toda la espera de entrada y salida. Cuando tu Worker lanza un fetch(), una lectura de KV o una consulta a D1 y se queda aguardando la respuesta, el procesador no está trabajando para ti: cede el hilo y atiende a otros. Ese tiempo de espera puede ser enorme y no suma un solo milisegundo a tu CPU time.

export default {
  async fetch(request, env, ctx): Promise<Response> {
    // esto NO cuenta como CPU: es espera de red pura
    const datos = await fetch("https://api.lenta.example.com/informe");

    // esto SI cuenta: el procesador trabaja de verdad
    const texto = await datos.text();
    const filas = texto.split("\n").map((l) => l.split(","));
    const total = filas.reduce((acc, f) => acc + Number(f[3]), 0);

    return Response.json({ total });
  },
};

En ese ejemplo, si la API tarda dos segundos en responder, esos dos segundos son tiempo de reloj pero no CPU. Lo que sí es CPU es partir el texto, mapearlo y sumarlo. Por eso un Worker puede vivir minutos esperando recursos lentos sin acercarse jamás a su límite, mientras que un bucle mal planteado sobre un millón de elementos puede fulminarlo en una fracción de segundo.

Los límites por plan

El tope de CPU time es por invocación y depende del plan. En el plan Free son 10 milisegundos de CPU por invocación: suficiente para un endpoint que transforma y responde, insuficiente para trabajo pesado. En el plan Paid, el valor por defecto es de 30 segundos, un margen enorme que rara vez se toca si tu código no tiene un error.

Y si de verdad necesitas más —piensa en hashear un fichero grande traído de R2 o en un cálculo criptográfico intenso—, puedes subir el límite hasta cinco minutos, es decir, 300000 milisegundos, con una sola clave en el manifiesto.

{
  "limits": {
    // por defecto son 30000 (30 s); el maximo es 300000 (5 min)
    "cpu_ms": 300000
  }
}

El valor por defecto de 30 segundos no es tacañería, es una red de seguridad: te protege de que un bucle infinito accidental dispare tu factura antes de que te des cuenta. Subir cpu_ms es una decisión consciente que tomas cuando sabes que tu carga es legítimamente intensa. Puedes incluso bajarlo por debajo de 30 segundos para acotar el gasto de un Worker del que desconfías.

Cómo medirlo y qué hacer al excederlo

Cuando tu Worker rebasa el límite, Cloudflare devuelve al cliente el error 1102, “Worker exceeded resource limits”. En el panel aparece como “Exceeded CPU Time Limits” bajo las estadísticas de invocación, y en analítica y Logpush el desenlace se marca como exceededCpu. Es una señal inequívoca: no es que el backend fuera lento, es que tu código trabajó demasiado.

flowchart LR
INV[Invocacion del Worker] --> CPU[Tiempo ejecutando codigo]
INV --> IO[Tiempo esperando red y almacenamiento]
CPU --> LIM{Supera el limite de cpu_ms}
IO --> FREE[No cuenta y no se cobra]
LIM -- si --> ERR[Error 1102 exceededCpu]
LIM -- no --> OK[Respuesta normal]
style CPU fill:#fab387,color:#11111b
style IO fill:#a6e3a1,color:#11111b
style ERR fill:#f38ba8,color:#11111b
style OK fill:#89b4fa,color:#11111b

Para localizar de dónde sale ese consumo, el camino es el perfilado de CPU con las DevTools que Wrangler expone: te muestra un desglose por función y revela el punto caliente exacto, casi siempre un bucle, una deserialización enorme o una expresión regular patológica. Medir antes de optimizar evita reescribir la parte que no era el problema.

Si el trabajo es legítimamente pesado y aun así choca contra el techo, tienes tres salidas. La primera es optimizar: recortar el algoritmo, evitar copias, usar estructuras más baratas. La segunda es trocear: partir el cálculo en fragmentos que se reparten entre varias peticiones o pasos. La tercera es delegarlo a una pieza pensada para durar —Durable Objects, Queues o Workflows—, que es justo lo que veremos al cerrar este nivel.