Am 13. November 2026 um 15:00 Uhr MEZ hat Cloudflare „Spend Management“ vorgestellt: Ausgabenlimits und E-Mail-Warnungen, zunächst als Beta für Kunden, deren Konto nach Verbrauch abgerechnet wird (Pay-as-you-go). Stand 13. November erfasst es nur Workers und Durable Objects^[1]. Changelog und Dokumentation tragen dasselbe Datum; weitere Produkte sollen bald folgen, einen Termin nennt Cloudflare nicht^[2][3].

Workers sind kleine Programme, die Cloudflare auf seinen Servern weltweit startet, sobald eine Anfrage eintrifft. Das Prinzip heißt Serverless: Sie betreiben keinen eigenen Server, der Anbieter führt den Code bei Bedarf aus und rechnet nach Verbrauch ab. Durable Objects geben solchen Programmen ein Gedächtnis, also dauerhaft gespeicherte Daten und Zustände, etwa für Chats oder Buchungen.

Genau diese Abrechnung nach Verbrauch ist das Risiko: Eine Endlosschleife im Code oder ein Ansturm automatisierter Anfragen treibt die Rechnung hoch, oft unbemerkt. Budget-Warnungen per E-Mail gab es bei Cloudflare schon vorher, sie stoppen aber nichts^[2]. Informieren sei nicht dasselbe wie Kontrollieren, schreibt Cloudflare selbst^[1].

Gezählt werden nur geschätzte Nutzungsgebühren über dem Inklusivvolumen, in US-Dollar und für den laufenden Abrechnungszeitraum. Bei Workers sind das Anfragen und CPU-Zeit, also die Rechenzeit des Prozessors. Bei Durable Objects zählen Anfragen, Laufzeit sowie Lese-, Schreib- und Löschvorgänge im Speicher, nicht aber die gespeicherte Datenmenge^[3].

Die Grundgebühr zählt ebenfalls nicht. Für den Bezahltarif Workers Paid beträgt sie laut Cloudflares Preisliste mindestens 5 US-Dollar im Monat pro Konto; enthalten sind unter anderem 10 Millionen Anfragen und 30 Millionen CPU-Millisekunden, jede weitere Million Anfragen kostet 0,30 US-Dollar^[4]. Workers AI, Workers KV und R2, Cloudflares Dienste für KI-Modelle, einfache Datenspeicher und Dateien, fallen nicht unter das Workers-Limit^[3].

Der Abrechnungszeitraum richtet sich nach dem Abo, nicht nach dem Kalendermonat: Verlängert sich das Abo am 15., setzt das Limit am 15. zurück^[1][3].

Greift das Limit, lehnt Cloudflare neue Aufrufe aller Worker im Konto ab: eingehende Webanfragen, Cron Triggers (zeitgesteuerte Aufgaben), die Abarbeitung von Warteschlangen, E-Mail-Worker und Aufrufe aus anderen Workern oder Durable Objects. Besucher sehen den Fehler 1103^[5].

Statische Dateien, die ohne Worker-Code ausgeliefert werden, bleiben erreichbar. Eine reine Informationsseite kann also weiterlaufen, während Formulare, Warenkorb oder Login ausfallen, sobald sie Worker-Code brauchen. Worker und Dateien werden nicht gelöscht^[5].

Bei Durable Objects lehnt Cloudflare neue Anfragen, Datenbankabfragen und neue Weckaufträge (Alarms) ab. Bereits offene WebSocket-Verbindungen, also Dauerverbindungen etwa für Live-Chats, laufen weiter, ebenso laufende Anfragen; gespeicherte Daten kosten weiter Geld. Ausstehende Alarme hält Cloudflare während der Sperre zurück; Alarme, die vor mehr als sieben Tagen angesetzt wurden, werden dabei gelöscht und müssen bei Bedarf neu angelegt werden^[6].

Cloudflare schreibt ausdrücklich, dass ein Limit keinen maximalen Rechnungsbetrag garantiert. Messverzögerungen, bereits laufende Vorgänge und Fehler bei der Durchsetzung können die Ausgaben über das Limit treiben; maßgeblich bleibt die Rechnung^[3].

Der Grund liegt in der Technik: Die Kosten erscheinen laut Cloudflare nahezu in Echtzeit, in unter zehn Minuten. Die Sperre wird danach asynchron an alle Server verteilt, die sie bei ihrer regelmäßigen Aktualisierung übernehmen. Den Abstand zwischen Messung und Sperre will Cloudflare verkürzen, „hoffentlich“ auf unter eine Minute^[1].

Zwei Fallstricke nennt die Doku: Ein neues Limit zählt die bereits angefallenen Kosten mit. Wer bei 60 US-Dollar Verbrauch ein Limit von 50 US-Dollar speichert, kann eine Sperre auslösen, sobald Cloudflare das Limit auswertet. Und Aus- und Wiedereinschalten setzt den Zähler nicht zurück^[3].

Aufheben lässt sich die Sperre, indem man das Limit über die aktuellen Kosten anhebt, abschaltet oder löscht; das kann einige Minuten dauern. Sonst endet sie mit dem nächsten Abrechnungszeitraum^[3].

Wer nur gewarnt werden will, schaltet die Option „Block usage“ aus und bekommt E-Mails, während die Anwendungen weiterlaufen^[2]. Unsere Faustregel: Wo ein Ausfall mehr kostet als eine überraschende Rechnung, etwa bei Shop, Buchungssystem oder Kundenportal, reicht oft die Warnung mit klarer Zuständigkeit. Wo ein Ausfall verschmerzbar ist, etwa bei Testumgebungen, internen Werkzeugen oder Experimenten, ist die harte Sperre die bessere Wahl.

Die Fragen, die Cloudflares Doku beantwortet, sollten Sie jedem Dienst stellen, der nach Verbrauch abrechnet:

• Warnt der Dienst nur, oder stoppt er auch?
• Wie schnell wird gemessen, wie schnell gesperrt?
• Was läuft trotz Sperre weiter und kostet weiter, etwa Speicher?
• Gilt die Grenze für Konto, Projekt oder Produkt, und was ist ausgenommen?
• Wer wird benachrichtigt, und wer darf die Sperre aufheben?

Ein Limit ersetzt weder Monitoring noch Schutz vor Missbrauch: Es greift erst, wenn das Budget schon verbraucht ist. Als Nächstes plant Cloudflare Budgets pro Anwendung und für KI-Agenten über mehrere Produkte hinweg, ohne konkreten Termin^[1]. Welche Kontrollen Agenten über Budgets hinaus brauchen, etwa bei Rechten, Zugangsdaten und Freigaben, beschreibt unser Beitrag KI-Agenten absichern.