Por que os alertas de orçamento do Firebase não param sua fatura

Um orçamento do Firebase ou do Google Cloud é um alerta, não um limite. Quando seus gastos ultrapassam 50%, 90% ou 100% do valor definido, o Google envia um e-mail ou uma mensagem do Pub/Sub, e nada mais acontece: suas leituras no Firestore, suas funções e seus downloads continuam rodando e sendo cobrados. O Google diz isso claramente na documentação do Cloud Billing: definir um orçamento apenas com alertas "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending." (ou seja, "não limita automaticamente o uso nem os gastos do Google Cloud ou da Google Maps Platform").

A documentação do Firebase repete: os alertas de orçamento "do not cap your usage or charges" ("não limitam seu uso nem suas cobranças"), eles são alertas "so that you can take action, if needed" ("para que você possa agir, se necessário") (planos de preços do Firebase). Alguém precisa ler o alerta e fazer alguma coisa. Essa é a lacuna.

Mesmo que alguém esteja de olho, o próprio alerta fica atrás dos gastos. O Google documenta três atrasos distintos:

• Relatório de custos. "There is a delay between your use of Google Cloud resources, and the usage costs reporting to Cloud Billing" ("há um atraso entre o uso dos recursos do Google Cloud e o registro dos custos no Cloud Billing") (documentação de orçamentos).
• Frequência das notificações. As notificações de orçamento vão para o Pub/Sub "multiple times per day" ("várias vezes ao dia"), não continuamente (notificações programáticas).
• Cálculo diário de uso. No Firebase, "Cloud Firestore and Cloud Storage usage are calculated daily" ("o uso do Cloud Firestore e do Cloud Storage é calculado diariamente") e "Cloud Functions usage is calculated monthly" ("o uso do Cloud Functions é calculado mensalmente") (evitar faturas inesperadas).

Em um orçamento recém-criado, o Google avisa que "may take several hours before receiving the first email or Pub/Sub notification" ("pode levar várias horas até receber o primeiro e-mail ou notificação do Pub/Sub"). Uma função presa em loop ou um script martelando seu banco de dados não espera tanto tempo.

Em 2026, o Firebase lançou os limites de gastos, em Preview. Eles são um avanço real, com duas limitações que vale conhecer:

• Eles cobrem apenas Firebase AI Logic, App Hosting, Cloud Functions for Firebase e Extensions. Firestore, Realtime Database e Cloud Storage não estão incluídos, e é justamente neles que acontece a maioria dos loops de leitura e das enxurradas de downloads.
• O próprio Google diz que os limites de gastos "are not 'hard caps'" ("não são limites rígidos"): eles agem sobre os mesmos dados de custo atrasados, e "any cost overages incurred during this delay will be billed as normal." ("qualquer excedente gerado durante esse atraso será cobrado normalmente").

Ative-os se você usa esses produtos. Só não os entenda como um teto para o projeto inteiro.

Algo precisa agir com base no alerta sem esperar por uma pessoa. Na prática:

1. Mandar seu app desacelerar. Desligue recursos caros, pause jobs em lote ou exiba uma página de manutenção enquanto investiga. Chamamos isso de Soft Kill.
2. Desconectar o faturamento como último recurso. Sem conta de faturamento, o Google interrompe todos os serviços pagos do projeto. Funciona mesmo que seu código esteja quebrado, mas tem consequências que você deve conhecer antes: o que acontece quando o faturamento para.
3. Detectar o pico antes do relatório de custos. As métricas de uso (leituras, invocações, bytes baixados) aparecem no Cloud Monitoring em minutos, muito antes do custo.

Você pode criar os dois primeiros por conta própria com uma função acionada pelo Pub/Sub (veja o kill switch faça você mesmo) ou deixar o FireShield executá-los para você: ele escuta as notificações do seu orçamento, executa um Soft Kill ou um Hard Kill nos limites que você escolher e, no plano Pro, monitora o uso de cada serviço em busca de picos.