Warum Firebase-Budgetwarnungen Ihre Rechnung nicht stoppen

Ein Firebase- oder Google-Cloud-Budget ist eine Warnung, kein Limit. Wenn Ihre Ausgaben 50 %, 90 % oder 100 % des festgelegten Betrags überschreiten, sendet Google eine E-Mail oder eine Pub/Sub-Nachricht, und sonst passiert nichts: Ihre Firestore-Lesevorgänge, Ihre Functions und Ihre Downloads laufen weiter und werden weiter abgerechnet. Google sagt es klar in der Cloud-Billing-Dokumentation: Ein reines Warnbudget "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending." (begrenzt also nicht automatisch Nutzung oder Ausgaben von Google Cloud oder Google Maps Platform).

Die Firebase-Dokumentation wiederholt es: Budgetwarnungen "do not cap your usage or charges" (begrenzen weder Ihre Nutzung noch Ihre Kosten), sie sind Warnungen, "so that you can take action, if needed" (damit Sie bei Bedarf handeln können) (Firebase-Tarife). Jemand muss die Warnung lesen und etwas tun. Genau da liegt die Lücke.

Selbst wenn jemand aufpasst, hinkt die Warnung selbst den Ausgaben hinterher. Google dokumentiert drei verschiedene Verzögerungen:

• Kostenmeldung. "There is a delay between your use of Google Cloud resources, and the usage costs reporting to Cloud Billing" (zwischen der Nutzung von Google-Cloud-Ressourcen und der Meldung der Kosten an Cloud Billing liegt eine Verzögerung) (Budget-Dokumentation).
• Benachrichtigungsrhythmus. Budgetbenachrichtigungen gehen "multiple times per day" (mehrmals täglich) an Pub/Sub, nicht kontinuierlich (programmatische Benachrichtigungen).
• Tägliche Nutzungsberechnung. Bei Firebase gilt: "Cloud Firestore and Cloud Storage usage are calculated daily" (die Nutzung von Cloud Firestore und Cloud Storage wird täglich berechnet) und "Cloud Functions usage is calculated monthly" (die Nutzung von Cloud Functions wird monatlich berechnet) (Überraschungsrechnungen vermeiden).

Bei einem neuen Budget warnt Google, es "may take several hours before receiving the first email or Pub/Sub notification" (kann es mehrere Stunden dauern, bis die erste E-Mail oder Pub/Sub-Benachrichtigung eintrifft). Eine Function in einer Endlosschleife oder ein Skript, das auf Ihre Datenbank einhämmert, wartet nicht so lange.

2026 hat Firebase Spend Caps (Ausgabenobergrenzen) eingeführt, als Preview. Sie sind ein echter Fortschritt, mit zwei Grenzen, die Sie kennen sollten:

• Sie decken nur Firebase AI Logic, App Hosting, Cloud Functions for Firebase und Extensions ab. Firestore, Realtime Database und Cloud Storage sind nicht abgedeckt, und genau dort passieren die meisten Leseschleifen und Download-Fluten.
• Google selbst sagt, Spend Caps "are not 'hard caps'" (sind keine „harten Obergrenzen“): Sie arbeiten mit denselben verzögerten Kostendaten, und "any cost overages incurred during this delay will be billed as normal." (alle während dieser Verzögerung angefallenen Mehrkosten werden normal abgerechnet).

Aktivieren Sie sie, wenn Sie diese Produkte nutzen. Verstehen Sie sie nur nicht als Obergrenze für das gesamte Projekt.

Etwas muss auf die Warnung reagieren, ohne auf einen Menschen zu warten. In der Praxis:

1. Sagen Sie Ihrer App, dass sie kürzertreten soll. Schalten Sie teure Funktionen ab, pausieren Sie Batch-Jobs oder zeigen Sie eine Wartungsseite, während Sie der Sache nachgehen. Wir nennen das einen Soft Kill.
2. Trennen Sie als letztes Mittel die Abrechnung. Ohne Rechnungskonto stoppt Google jeden kostenpflichtigen Dienst im Projekt. Das funktioniert auch, wenn Ihr Code kaputt ist, hat aber Folgen, die Sie vorher lesen sollten: was passiert, wenn die Abrechnung stoppt.
3. Erkennen Sie die Spitze vor der Kostenmeldung. Nutzungsmetriken (Lesevorgänge, Aufrufe, heruntergeladene Bytes) erscheinen innerhalb von Minuten in Cloud Monitoring, lange bevor die Kosten es tun.

Die ersten beiden können Sie selbst mit einer per Pub/Sub ausgelösten Function bauen (siehe den Kill Switch zum Selbstbauen), oder Sie überlassen sie FireShield: Es empfängt Ihre Budgetbenachrichtigungen, führt bei den von Ihnen gewählten Schwellenwerten einen Soft Kill oder einen Hard Kill aus und überwacht bei Pro die Nutzung jedes Dienstes auf Spitzen.