Cloudflare Workflows: retenção curta sem perder evidências

O padrão mudou; o limite, não

Um Workflow da Cloudflare é uma tarefa durável composta de etapas. A plataforma mantém estado suficiente para retomar o trabalho depois de uma espera ou nova tentativa e, após a conclusão ou um erro, preserva a instância finalizada por um período de retenção.

Essa instância retida é evidência operacional. A API de instâncias da Cloudflare pode retornar status, parâmetros, saída, detalhes das etapas, tentativas, tempos e erros. Se uma conciliação de pagamentos, uma importação de cliente ou uma publicação antiga falhou, é esse registro que ajuda a reconstituir o ocorrido.

A mudança de setembro tem três limites claros:

• Um Workflow no Workers Paid criado em 10 de setembro ou depois passa a ter, por padrão, sete dias de retenção do estado de instâncias concluídas e com erro.
• Um Workflow já existente mantém o comportamento de retenção atual. A Cloudflare não encurtou retroativamente a retenção dos Workflows antigos.
• O Workers Free continua com três dias, tanto como padrão quanto como limite.

No plano Paid, ainda é possível preservar o estado por até 30 dias. Portanto, a Cloudflare reduziu o padrão, não o máximo.

Essa diferença esclarece um conflito incômodo na documentação. A página de preços, atualizada pela última vez em 21 de julho, ainda apresenta 30 dias como o padrão do plano Paid. A referência da API do Workers, atualizada em 12 de agosto, informa que, sem uma configuração de retenção, vale o máximo da conta. As duas páginas são anteriores ao changelog de 10 de setembro.

Adote a regra mais nova e específica: sete dias são o padrão para Workflows Paid recém-criados. Workflows Paid existentes não mudam, e 30 dias continuam sendo o limite do plano.

Cloudflare Workflows: sete dias viraram prazo de incidente

A questão não é se sete dias parecem pouco. O que importa é saber se a equipe descobre falhas relevantes antes do sétimo dia.

Quem lidera o backend de rotinas de pagamento ou pedidos talvez só fique sabendo de uma divergência quando o suporte ou o financeiro fizer a conciliação. Se isso acontecer depois que a instância retida expirar, a equipe ainda poderá ter o registro da transação externa, mas terá perdido as tentativas das etapas, os detalhes do erro e as saídas do Workflow que explicam o caminho da execução.

Há outra armadilha para SREs. A Cloudflare mantém as métricas de Workflows consultáveis por 31 dias, mas essa janela de análise não equivale à retenção detalhada do estado da instância. Uma métrica pode mostrar que ocorreu uma falha. Ela não comprova que os parâmetros, as saídas, as tentativas e os erros daquela instância antiga ainda estejam disponíveis.

É a mesma regra operacional que vale para ferramentas de análise de falhas de agentes de IA: a retenção das evidências deve acompanhar o intervalo entre a falha e o momento em que alguém percebe sua importância.

Para quem lidera a área técnica de uma agência, o risco é a inconsistência. Um Workflow antigo de cliente, criado antes da mudança, pode manter a janela anterior; já um substituto criado depois da mudança recebe silenciosamente sete dias. O runbook do cliente pode estar errado, embora o caminho no código pareça o mesmo.

Separe o histórico barato de sucessos do histórico valioso de erros

A Cloudflare oferece dois controles por um motivo:

• successRetention define por quanto tempo o estado permanece depois de uma conclusão bem-sucedida.
• errorRetention define por quanto tempo o estado permanece depois de um encerramento com erro ou de uma interrupção.

Execuções bem-sucedidas costumam deixar o resultado durável do negócio em outro lugar: uma linha de pedido, uma chave de objeto, o ID de uma mensagem enviada ou o registro de uma importação concluída. Quando esse sistema externo é a fonte da verdade, uma janela curta para sucessos pode bastar para as verificações imediatas de suporte e reexecução.

Com erros, a situação muda. Muitas vezes, o maior valor está justamente no caminho inacabado. A etapa que falhou, as tentativas anteriores, os parâmetros de entrada e a saída intermediária podem ser essenciais para a investigação. Se as falhas demoram a aparecer, é mais fácil justificar uma janela maior para erros do que preservar todas as execuções bem-sucedidas pelo mesmo período.

O exemplo oficial da mudança faz essa separação de forma direta:

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

É apenas um exemplo, não uma recomendação universal. Defina a janela de erros a partir do maior atraso plausível para descobrir e investigar um problema. Para sucessos, considere por quanto tempo a operação precisa consultar o registro do Workflow depois que o resultado real já chegou ao sistema responsável por armazená-lo.

A conta do armazenamento só fecha quando o estado ativo fica separado

A Cloudflare cobra o armazenamento de Workflows em GB-month. No Workers Paid, o primeiro 1 GB-month está incluído, e o armazenamento adicional custa $0.20 por GB-month. A Cloudflare calcula essa medida usando a média do pico diário de armazenamento ao longo de um período de faturamento de 30 dias.

O total de armazenamento abrange instâncias em execução, em espera, com erro e concluídas. Uma retenção menor após o término pode reduzir o espaço consumido pelos estados finalizados, mas não elimina o estado dos trabalhos que ainda estão ativos ou em espera.

A página de preços atual informa que a cobrança por etapas e armazenamento de Workflows começa em 10 de agosto de 2026. O aviso de faturamento mais antigo, publicado em julho, dizia apenas que a cobrança não começaria antes dessa data. A página atual define a data de início publicada, mas ainda não comprova o que uma conta específica mostrará na próxima fatura.

O modelo a seguir é explicitamente hipotético: não é um benchmark da Cloudflare nem uma economia prometida.

Considere que as execuções bem-sucedidas adicionem 1 GB de novo estado retido por dia, com volume constante. As instâncias ativas, em execução e em espera contribuem com mais 0.5 GB-month nos dois cenários. Para isolar o efeito da retenção de sucessos, a comparação exclui o armazenamento de estados com erro. Se errorRetention continuar em 30 dias, meça esse estado e acrescente a mesma linha de histórico de erros aos dois lados.

A diferença projetada é de $4.60. É justamente por isso que as premissas precisam estar explícitas. Uma equipe cujas etapas geram saídas minúsculas talvez não economize quase nada. Um Workflow de alto volume que armazena resultados grandes pode ter uma parcela muito maior de sucessos retidos. O novo padrão muda o multiplicador, mas são o tamanho do estado e a taxa de conclusão que determinam a conta.

Os limites, sem maquiagem

Trinta dias continuam sendo o máximo no plano Paid. Se um cliente, um órgão regulador ou uma conciliação mensal puder revelar um problema depois dessa janela, o estado das instâncias do Workflows não pode ser seu único arquivo. Exporte as evidências mínimas necessárias para um sistema com políticas próprias de retenção e acesso.

Uma retenção maior para erros também guarda mais estado de erro. A política correta não é “erros para sempre”. O prazo deve bastar para descobrir e reconstituir o incidente e, em seguida, dar lugar a um registro durável e compacto, como o ID da instância, a versão do workflow, os timestamps, o status, o erro com dados sensíveis removidos e o objeto de negócio afetado.

A retenção curta de sucessos também depende de uma condição: o resultado bem-sucedido já precisa estar armazenado em algum lugar confiável. Se a saída do Workflow for o único registro de que uma ação ocorreu, apagá-la antes reduz tanto o armazenamento quanto as evidências.

Por fim, substituições por instância podem fragmentar a política. Uma agência com vários caminhos de criação pode configurar corretamente o padrão no painel e, ainda assim, ter uma chamada solicitando outra janela. A retenção deve entrar na revisão de código, no runbook e no modelo de custos — não ficar restrita a uma configuração no painel.

O que fazer agora

Tome providências nesta semana se você criou um Workflow Paid em 10 de setembro ou depois, se uma falha pode levar mais de sete dias para chegar ao responsável ou se o estado concluído representa uma linha visível do armazenamento. Defina separadamente a retenção de sucessos e erros.

Deixe a otimização para depois se o Workflow ainda for um piloto de baixo volume e o estado retido couber no 1 GB-month incluído. Mesmo assim, explicite a política: a janela de investigação importa até quando o excedente de armazenamento é zero.

A mudança de padrão não afeta Workflows que já existiam antes de 10 de setembro. O Workers Free também permanece igual, com padrão e limite de três dias. Em nenhum dos casos deixa de ser necessário manter um registro externo quando o negócio precisa investigar além da janela da plataforma.

Na segunda-feira, audite todos os caminhos usados para criar novos Workflows. Defina successRetention e errorRetention explicitamente, dispare uma falha segura e confirme o último dia em que o estado detalhado ainda poderá ser inspecionado. Registre essa data no runbook antes que o primeiro incidente real faça o teste por você.

Receba a próxima mudança prática de plataforma na newsletter.