Cloudflare Workers acorta el historial de Workflows: cómo ajustar la retención

Qué cambió en Cloudflare Workers: el valor predeterminado, no el límite

Un Workflow de Cloudflare es un trabajo duradero compuesto por pasos. La plataforma conserva el estado necesario para reanudarlo después de una espera o un reintento y, una vez que termina correctamente o con error, guarda la instancia durante un periodo de retención.

Esa instancia retenida es evidencia operativa. La API de instancias de Cloudflare puede devolver su estado, parámetros, salida, detalles de los pasos, intentos, tiempos y errores. Si una conciliación de pagos, una importación de clientes o una tarea de publicación antigua dio error, ese registro permite reconstruir lo ocurrido.

El cambio de septiembre tiene tres límites claros:

• Un Workflow de Workers Paid creado el 10 de septiembre o después conserva por defecto durante siete días el estado de las instancias completadas y con error.
• Los Workflows existentes conservan su política de retención actual. Cloudflare no acortó de forma retroactiva la retención de los Workflows antiguos.
• Workers Free se mantiene en tres días, tanto como valor predeterminado como límite.

El plan Paid todavía permite conservar el estado hasta 30 días. Cloudflare redujo el valor predeterminado, no el máximo.

Esta diferencia aclara una contradicción incómoda en la documentación. La página de precios, actualizada por última vez el 21 de julio, aún presenta 30 días como el valor predeterminado de Paid. La referencia de la API de Workers, actualizada el 12 de agosto, indica que, si se omite la configuración de retención, se aplica el máximo de la cuenta. Ambas páginas son anteriores al registro de cambios del 10 de septiembre.

Conviene seguir la regla más reciente y específica: siete días es el valor predeterminado para los nuevos Workflows de Paid. Los Workflows existentes de Paid no cambian y 30 días sigue siendo el límite del plan.

Siete días son ahora el plazo para investigar un incidente

La pregunta relevante no es si siete días parecen pocos, sino si el equipo detecta los errores importantes antes del séptimo día.

Quien dirige un backend con tareas de pagos o pedidos quizá no se entere de una discrepancia hasta que soporte o finanzas concilien los registros. Si eso ocurre después de que venza la instancia retenida, el equipo aún puede disponer del registro de la transacción externa, pero habrá perdido los intentos de los pasos, los detalles del error y las salidas del Workflow que explican la ruta de ejecución.

Para un SRE existe otra trampa. Cloudflare permite consultar las métricas de Workflows durante 31 días, pero esa ventana analítica no equivale a la retención detallada del estado de una instancia. Una métrica puede confirmar que ocurrió un error; no demuestra que sigan disponibles los parámetros, las salidas, los intentos y los errores de la instancia antigua.

Es la misma regla operativa que se aplica a las herramientas de análisis de errores de agentes de IA: el periodo de conservación de la evidencia debe cubrir el tiempo entre el error y el momento en que alguien advierte su importancia.

Para el responsable técnico de una agencia, el riesgo es la incoherencia. Un Workflow de cliente creado antes del cambio puede conservar su ventana anterior, mientras que otro que lo sustituya después queda configurado silenciosamente con siete días. El manual operativo del cliente puede quedar desactualizado aunque la ruta del código parezca idéntica.

Separe el historial de ejecuciones correctas de la evidencia de errores

Cloudflare ofrece dos controles por una razón:

• successRetention determina cuánto tiempo se conserva el estado después de una finalización correcta.
• errorRetention determina cuánto tiempo se conserva después de que la ejecución termina con error o se cancela.

Las ejecuciones correctas suelen dejar su resultado de negocio persistente en otro lugar: una fila de pedido, una clave de objeto, el identificador de un mensaje enviado o el registro de una importación completada. Cuando ese sistema externo es la fuente de verdad, una ventana breve para los éxitos puede bastar para las comprobaciones inmediatas de soporte y reprocesamiento.

Con los errores ocurre lo contrario. Su valor suele estar en la propia ruta inconclusa. El paso fallido, los intentos anteriores, los parámetros de entrada y la salida intermedia pueden ser justo lo que necesita quien investiga. Si los errores pueden detectarse tarde, es más fácil justificar una ventana larga para ellos que conservar todas las ejecuciones correctas durante el mismo periodo.

El ejemplo oficial del cambio muestra directamente esa separación:

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

Es un ejemplo, no una recomendación universal. Defina la ventana de errores a partir del mayor retraso realista entre el incidente, su descubrimiento y la investigación. Defina la ventana de éxitos según el tiempo que los operadores necesiten consultar el registro del Workflow después de que el resultado real llegue a su sistema oficial de registro.

El cálculo de almacenamiento solo funciona si separa el estado activo

Cloudflare factura el almacenamiento de Workflows en GB-mes. En Workers Paid, el primer 1 GB-mes está incluido y el almacenamiento adicional cuesta $0.20 por GB-mes. Cloudflare calcula esta medida promediando el pico diario de almacenamiento durante un periodo de facturación de 30 días.

El total de almacenamiento abarca las instancias en ejecución, en espera, con error y completadas. Por tanto, una retención terminal más breve puede reducir el almacenamiento del estado finalizado, pero no elimina el estado de las tareas que siguen activas o en espera.

La página de precios actual indica que la facturación de pasos y almacenamiento de Workflows se aplica desde el 10 de agosto de 2026. El aviso de facturación anterior, publicado en julio, solo prometía que la facturación no comenzaría antes de esa fecha. La página actual fija la fecha de inicio publicada, pero aun así no demuestra qué aparecerá en la próxima factura de una cuenta concreta.

El siguiente modelo es expresamente hipotético: no es un benchmark de Cloudflare ni promete un ahorro.

Supongamos que las ejecuciones correctas añaden 1 GB de estado recién retenido al día con un volumen estable. Las instancias activas, en ejecución y en espera aportan otros 0.5 GB-mes en ambos escenarios. Para aislar el efecto de la retención de éxitos, se excluye de la comparación el almacenamiento del estado con error. Si errorRetention se mantiene en 30 días, mida ese estado y añada la misma línea de historial de errores a ambos lados.

La diferencia estimada es de $4.60. Precisamente por eso hay que identificar los supuestos. Un equipo cuyos pasos generen salidas diminutas podría no ahorrar casi nada. Un Workflow de gran volumen que conserve resultados grandes puede tener una partida mucho mayor de éxitos retenidos. El nuevo valor predeterminado cambia el multiplicador, pero el tamaño del estado y la tasa de finalización determinan la factura.

Los límites que conviene reconocer

Treinta días sigue siendo el máximo de Paid. Si un cliente, un regulador o una conciliación mensual puede descubrir un problema después de esa ventana, el estado de las instancias de Workflows no puede ser el único archivo. Exporte la evidencia mínima necesaria a un sistema con su propia política de retención y acceso.

Una ventana de errores más larga también conserva más estado de error. La política correcta no es «errores para siempre», sino disponer de tiempo suficiente para descubrir y reconstruir el incidente y, después, conservar un registro duradero y compacto, como el identificador de la instancia, la versión del Workflow, las marcas de tiempo, el estado, el error redactado y el objeto de negocio afectado.

Una retención breve de los éxitos también tiene una condición: el resultado correcto ya debe existir en un lugar confiable. Si la salida del Workflow es el único registro de que una acción ocurrió, eliminarla antes reduce tanto el almacenamiento como la evidencia.

Las configuraciones específicas de cada instancia también pueden fragmentar la política. Una agencia con varias rutas de creación puede configurar bien el valor predeterminado del panel y aun así tener una llamada que solicite otra ventana. La retención debe formar parte de la revisión de código, el manual operativo y el modelo de costos, no solo de la configuración del panel.

Qué hacer ahora

Actúe esta semana si creó un Workflow de Paid el 10 de septiembre o después, si un error puede tardar más de siete días en llegar a su responsable o si el estado completado ocupa una partida visible de almacenamiento. Configure por separado la retención de éxitos y la de errores.

Posponga la optimización si el Workflow todavía es un piloto de bajo volumen y su estado retenido cabe en el primer 1 GB-mes incluido. Aun así, haga explícita la política: la ventana de investigación importa incluso cuando el excedente de almacenamiento es cero.

El cambio del valor predeterminado no le afecta si el Workflow ya existía antes del 10 de septiembre. Workers Free tampoco cambia: conserva un valor predeterminado y un límite de tres días. Ninguno de los dos casos elimina la necesidad de un registro externo cuando el negocio debe investigar más allá de la ventana de la plataforma.

El lunes, audite todas las rutas de creación de nuevos Workflows. Configure de forma explícita successRetention y errorRetention, provoque después un error controlado y confirme el último día en que todavía podrá consultar su estado detallado. Anote esa fecha en el manual operativo antes de que el primer incidente real ponga a prueba la política.

Reciba por correo el próximo cambio práctico de las plataformas.