El 13 de noviembre de 2026 Cloudflare abrió Spend Management, en beta, a todos los clientes pay-as-you-go. Por primera vez se puede fijar un tope de gasto para Workers y para Durable Objects y hacer que la plataforma deje de ejecutar cuando se alcanza. Hasta ahora solo había notificaciones de uso y alertas de presupuesto, que avisan y dejan todo funcionando. La configuración está en Billing > Spend limits en el panel, en el CLI cf y en la API de facturación, donde cada regla se llama spend policy.
El detalle que pesa en la decisión es que el límite es por producto y por cuenta. No se puede aplicar a un Worker concreto, a un namespace de Durable Objects ni a un entorno.
Qué se detiene al llegar al tope
En Workers, el límite suma solicitudes y tiempo de CPU después del uso incluido en el plan. La suscripción de Workers Paid queda fuera, igual que KV, R2, Workers AI y cualquier otro producto. Al alcanzar el monto, Cloudflare rechaza nuevas invocaciones de todos los Workers de la cuenta: solicitudes HTTP (el visitante recibe el error 1103), Cron Triggers, consumidores de Queues, Email Workers y llamadas desde otros Workers o Durable Objects. Los assets estáticos servidos sin ejecutar el Worker siguen en línea; las rutas con run_worker_first pueden fallar.
En Durable Objects cuentan solicitudes, duración, filas leídas y escritas en SQLite y operaciones de almacenamiento clave-valor. Con el bloqueo activo se rechazan nuevas solicitudes por el stub, consultas SQL, crecimiento del almacenamiento y nuevos setAlarm(). Las alarmas pendientes quedan retenidas, y la documentación advierte que una alarma programada hace más de siete días se borra durante la retención; la aplicación tiene que volver a crearla. Algunas cosas siguen generando cargos: solicitudes ya en curso, mensajes en WebSockets ya abiertos, operaciones en objetos antiguos basados en clave-valor y los datos almacenados.
Por eso la propia documentación dice que el límite no garantiza un monto máximo de factura. Según el anuncio, el gasto se calcula con un retraso de hasta diez minutos, y la propagación del bloqueo también lleva tiempo.
Quién debe revisarlo con cuidado
Quien tiene producción y pruebas en la misma cuenta. La documentación da el ejemplo: un Worker de prueba puede agotar el límite compartido y tumbar un Worker de producción de la misma cuenta. El mismo razonamiento vale para quien aloja varios clientes o productos en una sola cuenta: el tope de uno se vuelve el tope de todos.
También cambia poco para quien tiene costos dominados por R2, KV o Workers AI, porque esos cargos no entran en el límite de Workers. Para inferencia, Cloudflare remite a los límites de AI Gateway, que funcionan por usuario, modelo o proveedor.
El periodo que se considera es el ciclo de la suscripción, no el mes calendario. Si la suscripción se renueva el día 15, el contador se reinicia el día 15.
Qué hacer ahora
Nada es obligatorio: el límite solo aplica a quien lo configure. La elección es entre arriesgar una factura alta o una interrupción, el mismo intercambio entre previsibilidad de la factura y disponibilidad que aparece en El precio fijo del CDN también depende del tramo de uso.
Para una cuenta con un producto que genera ingresos, el camino de menor riesgo es la alerta por correo sin bloqueo (con Block usage desactivado), que avisa al 80% y al 100% del monto y deja la aplicación funcionando. El bloqueo tiene más sentido en una cuenta separada para experimentos, previews o agentes, donde detenerse es mejor que pagar.
Si se activa el bloqueo, algunos cuidados vienen de la propia documentación:
- revisar el gasto ya acumulado en el ciclo antes de guardar: un límite de 50 dólares en una cuenta que ya va en 60 pausa el producto en cuanto se evalúa la regla;
- el límite creado desde el panel no tiene destinatario de correo; hay que agregar
notification_emailpor el CLI o la API para recibir avisos; - quien depende de alarmas de Durable Objects tiene que saber cuáles podrían quedar retenidas más de siete días y cómo recrearlas;
- para volver a estar en línea hay que subir el límite por encima del gasto actual, desactivarlo o eliminarlo, y el cambio tarda unos minutos en aplicarse.
El registro de quién cambió cada límite aparece en el panel y en los Audit Logs de la cuenta, lo que ayuda a definir quién puede modificarlo.
Lo que todavía no se sabe
Cloudflare dice que otros productos llegarán "pronto", sin lista ni fecha. El tiempo entre la medición y el bloqueo debería bajar a menos de un minuto, según el anuncio, también sin plazo. Los presupuestos por aplicación o por tarea de agente, que resolverían el problema de un límite que vale para toda la cuenta, están en los planes y todavía no existen. No hay fecha para el fin del beta.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
