Michael JohnsonÉ possível limitar os gastos com computação em nuvem sem correr o risco de interromper um aplicativo em produção? Na Cloudflare, agora há opções para ambos os casos, mas o limite rígido funciona como um interruptor para o produto em toda a conta: ao atingir o valor definido, ele bloqueia novas operações compatíveis. O limite, porém, não garante um valor máximo na fatura.
Em 13 de novembro de 2026, a Cloudflare anunciou o lançamento do Spend Management para clientes Pay-as-you-go. No início, os limites e alertas estão disponíveis para Workers e Durable Objects. É uma proteção automática contra aumentos inesperados no consumo — desde que a equipe entenda quais serviços ficarão sujeitos à mesma interrupção, conforme explica a Cloudflare.
O que mudou em relação aos alertas de gastos?
Um alerta informa que os gastos chegaram ao nível escolhido, enquanto o produto continua funcionando. Um limite rígido bloqueia as operações compatíveis. No Spend Management, cada produto tem uma política própria: valor do limite, níveis de alerta e, se configurado, endereço de e-mail. Os limites de Workers e Durable Objects são independentes e abrangem todo o produto correspondente na conta. Não é possível configurar um limite para um único Worker, um namespace específico de Durable Objects ou uma métrica individual, segundo a documentação da Cloudflare.
A escolha prática é simples: o alerta é indicado quando a disponibilidade é prioritária; o limite que bloqueia operações é adequado quando a equipe aceita interromper as operações compatíveis do produto para conter o consumo adicional.
Por que o limite não é acionado exatamente no valor definido?
A contabilização dos gastos e a propagação do bloqueio não acontecem instantaneamente. A Cloudflare descreve o painel como uma ferramenta que mostra os gastos quase em tempo real — em menos de 10 minutos —, mas o mecanismo de cálculo de custos não fica no caminho de cada solicitação. A política é propagada de forma assíncrona pelos nós da rede, e o ambiente de execução a aplica quando atualiza periodicamente o estado local. É assim que a Cloudflare explica o funcionamento do Spend Management.
Por isso, o valor definido é o ponto a partir do qual o bloqueio deve começar, não um teto rígido para a fatura final. Enquanto os gastos são contabilizados e a regra se propaga, as operações podem continuar. Algumas cobranças também não entram no limite: por exemplo, a tarifa de assinatura Workers Paid é excluída, e os dados armazenados em Durable Objects podem continuar gerando gastos depois da pausa. A Cloudflare alerta que o valor final aparece na fatura.
Que partes do aplicativo o limite de Workers vai interromper?
O limite de Workers reúne os gastos com solicitações e tempo de CPU de todos os Workers da conta, após a dedução do volume incluído. Quando o bloqueio entra em vigor, a Cloudflare rejeita novas chamadas de código que gerem gastos. Recursos estáticos servidos sem executar código do Worker continuam funcionando. Esse escopo está descrito na documentação de Workers.
Imagine uma conta com um aplicativo em produção e um Worker de teste. Se a carga de teste elevar os gastos totais de Workers até o limite, o bloqueio também poderá afetar o código de produção na mesma conta. Não há limites separados por aplicativo; para isolar os impactos, a equipe pode separar as cargas relevantes em contas distintas ou optar por alertas, se uma interrupção de Workers for inaceitável.
Um limite separado para Durable Objects contabiliza solicitações, duração de execução, leitura e gravação de linhas SQLite, além de operações de leitura, gravação e exclusão no armazenamento de chave-valor. Ele não inclui Workers, Workers AI, KV, R2 nem outros produtos. Se o aplicativo depender de vários serviços, um único limite protegerá apenas a parte correspondente dos gastos, e a interrupção de um dos componentes ainda poderá afetar o funcionamento do aplicativo.
O que verificar antes de ativar o bloqueio?
Mapeie as dependências da conta: quais aplicativos usam Workers, quais tarefas em segundo plano acionam agendamentos ou filas e quais serviços chamam Durable Objects. Em seguida, decida para quais produtos uma interrupção automática é aceitável. Se uma falha for pior do que um gasto excedente, configure um alerta sem bloqueio. Se o bloqueio for aceitável, escolha um valor que leve em conta o atraso no processamento, as cotas incluídas e os gastos excluídos do limite.
A Cloudflare descreve a configuração pelo painel de controle, pelo cf CLI e pela API REST. Por exemplo, ao criar uma política na API, são usados os campos threshold_cents para o valor em centavos, product_id para o produto, action para a ação e notification_email para os alertas; há um exemplo no anúncio da empresa. Automatizar a configuração não altera o escopo: o limite continua valendo para todo o produto na conta.
Defina também, com antecedência, um procedimento de recuperação. Para suspender o bloqueio antes do próximo período de cobrança, a Cloudflare recomenda aumentar o limite para um valor acima dos gastos acumulados, desativá-lo ou excluir a política. As alterações podem levar alguns minutos para entrar em vigor; reativar o mesmo limite não zera os gastos do período atual.
Quando esse mecanismo é útil?
O Spend Management acrescenta uma resposta automática ao aumento do consumo: em vez de apenas enviar um e-mail, o sistema pode interromper novas operações compatíveis do produto selecionado. Para uma conta com tarefas de teste, isso pode servir de proteção contra uma carga descontrolada. Em uma conta com vários serviços críticos, o limite comum vincula o orçamento à disponibilidade de todos os Workers ou de todos os Durable Objects da conta.
A decisão depende do custo aceitável de uma interrupção. Se a continuidade do serviço for prioritária, comece com alertas e monitore os gastos. Se for mais importante conter o uso adicional, ative o bloqueio depois de verificar as dependências e preparar a recuperação. Planeje o limite como uma política de interrupção do produto, não como uma promessa de valor exato na fatura.
