Perché gli avvisi di budget di Firebase non fermano la tua fattura

Un budget di Firebase o Google Cloud è un avviso, non un limite. Quando la tua spesa supera il 50%, il 90% o il 100% dell'importo impostato, Google invia un'email o un messaggio Pub/Sub, e non succede nient'altro: le letture Firestore, le funzioni e i download continuano a girare e a essere fatturati. Google lo dice chiaramente nella documentazione di Cloud Billing: impostare un budget solo con avvisi "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending." (cioè, «non limita automaticamente l'utilizzo o la spesa di Google Cloud o Google Maps Platform»).

La documentazione di Firebase lo ripete: gli avvisi di budget "do not cap your usage or charges" (cioè, «non limitano il tuo utilizzo né i tuoi addebiti»), sono avvisi "so that you can take action, if needed" (cioè, «così che tu possa intervenire, se necessario») (Piani tariffari di Firebase). Qualcuno deve leggere l'avviso e fare qualcosa. È lì il problema.

Anche se qualcuno sta guardando, l'avviso stesso è in ritardo rispetto alla spesa. Google documenta tre ritardi distinti:

• Rendicontazione dei costi. "There is a delay between your use of Google Cloud resources, and the usage costs reporting to Cloud Billing" (cioè, «c'è un ritardo tra l'uso delle risorse Google Cloud e la comunicazione dei costi a Cloud Billing») (documentazione sui budget).
• Frequenza delle notifiche. Le notifiche di budget arrivano a Pub/Sub "multiple times per day" (cioè, «più volte al giorno»), non in modo continuo (notifiche programmatiche).
• Calcolo giornaliero dell'utilizzo. Per Firebase, "Cloud Firestore and Cloud Storage usage are calculated daily" (cioè, «l'utilizzo di Cloud Firestore e Cloud Storage è calcolato ogni giorno») e "Cloud Functions usage is calculated monthly" (cioè, «l'utilizzo di Cloud Functions è calcolato ogni mese») (evitare fatture a sorpresa).

Su un budget appena creato, Google avverte che "may take several hours before receiving the first email or Pub/Sub notification" (cioè, «possono passare diverse ore prima di ricevere la prima email o notifica Pub/Sub»). Una funzione bloccata in un ciclo o uno script che martella il tuo database non aspetta così a lungo.

Nel 2026 Firebase ha aggiunto i limiti di spesa, in Preview. Sono un vero passo avanti, con due limiti da conoscere:

• Coprono solo Firebase AI Logic, App Hosting, Cloud Functions for Firebase ed Extensions. Firestore, Realtime Database e Cloud Storage non sono coperti, ed è lì che avviene la maggior parte dei cicli di lettura e delle ondate di download.
• Google stessa dice che i limiti di spesa "are not 'hard caps'" (cioè, «non sono limiti rigidi»): agiscono sugli stessi dati di costo in ritardo, e "any cost overages incurred during this delay will be billed as normal." (cioè, «qualsiasi eccedenza di costo sostenuta durante questo ritardo verrà fatturata normalmente»).

Attivali se usi quei prodotti. Solo, non considerarli un tetto per l'intero progetto.

Qualcosa deve agire sull'avviso senza aspettare un essere umano. In pratica:

1. Di' alla tua app di rallentare. Disattiva le funzionalità costose, sospendi i job batch o mostra una pagina di manutenzione mentre indaghi. Lo chiamiamo Soft Kill.
2. Scollega la fatturazione come ultima risorsa. Senza account di fatturazione, Google interrompe ogni servizio a pagamento del progetto. Funziona anche se il tuo codice è rotto, ma ha conseguenze che dovresti leggere prima: cosa succede quando la fatturazione si ferma.
3. Intercetta il picco prima del report dei costi. Le metriche di utilizzo (letture, invocazioni, byte scaricati) compaiono in Cloud Monitoring in pochi minuti, molto prima del costo.

Puoi costruire le prime due da solo con una funzione attivata da Pub/Sub (vedi il kill switch fai da te), oppure lasciare che sia FireShield a gestirle: ascolta le notifiche del tuo budget, esegue un Soft Kill o un Hard Kill alle soglie che scegli e, su Pro, controlla l'utilizzo di ogni servizio per rilevare i picchi.