Cloudflare Workflows: Aufbewahrung und Speicherkosten richtig planen

Bei Cloudflare Workflows änderte sich der Standard, nicht die Obergrenze

Ein Cloudflare Workflow ist ein langlebiger Prozess, der aus einzelnen Schritten besteht. Die Plattform speichert genügend Zustand, um ihn nach einer Wartephase oder einem Wiederholungsversuch fortzusetzen. Nach dem erfolgreichen Abschluss oder einem Fehler bleibt die fertige Instanz für eine festgelegte Aufbewahrungsdauer erhalten.

Diese aufbewahrte Instanz ist ein operativer Beleg. Die Instanz-API von Cloudflare kann Status, Parameter, Ausgabe, Details zu einzelnen Schritten, Versuche, Zeitangaben und Fehler zurückgeben. Ist etwa ein älterer Zahlungsabgleich, Kundenimport oder Veröffentlichungsauftrag fehlgeschlagen, lässt sich anhand dieses Datensatzes rekonstruieren, was passiert ist.

Für die Änderung im September gelten drei Grenzen:

• Ein Workflow unter Workers Paid, der am oder nach dem 10. September angelegt wird, verwendet für den Zustand abgeschlossener und fehlerhafter Instanzen standardmäßig sieben Tage.
• Ein bestehender Workflow behält sein bisheriges Aufbewahrungsverhalten. Cloudflare hat die Frist alter Workflows nicht rückwirkend verkürzt.
• Bei Workers Free bleibt es bei drei Tagen – sowohl als Standard als auch als Obergrenze.

Im Paid-Tarif lässt sich der Zustand weiterhin bis zu 30 Tage aufbewahren. Cloudflare hat also den Standard gesenkt, nicht das Maximum.

Diese Unterscheidung löst einen unangenehmen Widerspruch in der Dokumentation auf. Die zuletzt am 21. Juli aktualisierte Preisseite bezeichnet 30 Tage weiterhin als Paid-Standard. Die am 12. August aktualisierte Workers-API-Referenz besagt, dass ohne Aufbewahrungseinstellung das Kontomaximum gilt. Beide Seiten sind älter als der Changelog vom 10. September.

Maßgeblich ist die neuere und präzisere Regel: Bei neu angelegten Paid Workflows beträgt der Standard sieben Tage. Bestehende Paid Workflows bleiben unverändert, die Obergrenze liegt weiterhin bei 30 Tagen.

Sieben Tage werden zur Frist für die Störungsanalyse

Entscheidend ist nicht, ob sieben Tage kurz klingen. Entscheidend ist, ob wichtige Fehler im Team vor Ablauf des siebten Tages bekannt werden.

Wer als Backend-Verantwortlicher Zahlungs- oder Bestellprozesse betreut, erfährt womöglich erst von einer Abweichung, wenn Support oder Finanzabteilung den Datensatz abgleichen. Ist die aufbewahrte Instanz dann bereits verfallen, kann der externe Transaktionsdatensatz zwar noch existieren. Doch die Schrittversuche, Fehlerdetails und Ausgaben des Workflows, die den Ausführungspfad erklären, sind verloren.

Für SRE-Teams gibt es eine zweite Falle. Cloudflare hält Workflow-Metriken 31 Tage lang abfragbar, doch dieses Analysefenster ist nicht mit der Aufbewahrung detaillierter Instanzzustände gleichzusetzen. Eine Metrik kann zeigen, dass ein Fehlerereignis aufgetreten ist. Sie beweist nicht, dass Parameter, Ausgaben, Versuche und Fehler der alten Instanz noch verfügbar sind.

Hier gilt dieselbe Betriebsregel wie bei Tools zur Fehleranalyse von KI-Agenten: Die Aufbewahrung von Belegen muss zu der Zeitspanne passen, die zwischen dem Fehler und dem Moment liegt, in dem jemand seine Bedeutung erkennt.

Für technische Verantwortliche in Agenturen liegt die Gefahr in der Inkonsistenz. Ein lang laufender Kunden-Workflow, der vor der Änderung angelegt wurde, kann sein altes Zeitfenster behalten. Ein danach erstellter Ersatz erhält dagegen unbemerkt sieben Tage. So kann das Betriebshandbuch des Kunden falsch sein, obwohl der Codepfad unverändert aussieht.

Kurze Erfolgshistorie von wertvoller Fehlerhistorie trennen

Cloudflare stellt aus gutem Grund zwei Stellschrauben bereit:

• successRetention bestimmt, wie lange der Zustand nach einem erfolgreichen Abschluss erhalten bleibt.
• errorRetention bestimmt, wie lange der Zustand nach einem fehlerhaften oder abgebrochenen Ende erhalten bleibt.

Erfolgreiche Läufe hinterlassen ihr dauerhaftes Geschäftsergebnis häufig in einem anderen System: etwa in einer Bestellzeile, einem Objektschlüssel, der ID einer versendeten Nachricht oder einem abgeschlossenen Importdatensatz. Ist dieses externe System die maßgebliche Datenquelle, kann ein kurzes Erfolgsfenster für unmittelbare Support- und Wiederholungsprüfungen genügen.

Bei fehlerhaften Läufen ist das anders. Wertvoll ist hier oft gerade der unvollständige Pfad. Der fehlgeschlagene Schritt, frühere Versuche, Eingabeparameter und Zwischenausgaben können für die Untersuchung entscheidend sein. Wenn Fehler erst spät auffallen, lässt sich ein längeres Fehlerfenster leichter rechtfertigen, als jeden erfolgreichen Lauf ebenso lange aufzubewahren.

Das offizielle Änderungsbeispiel setzt diese Trennung direkt um:

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

Das ist ein Beispiel, keine allgemeingültige Empfehlung. Das Fehlerfenster sollte sich am längsten realistischen Zeitraum bis zur Entdeckung und Untersuchung orientieren. Für das Erfolgsfenster zählt, wie lange der Workflow-Datensatz nach dem Eingang des eigentlichen Ergebnisses im führenden System noch für den Betrieb benötigt wird.

Speicherrechnung: Aktiven Zustand separat behandeln

Cloudflare berechnet Workflow-Speicher in GB-Monaten. Bei Workers Paid ist das erste Kontingent von 1 GB-Monat enthalten, zusätzlicher Speicher kostet $0.20 pro GB-Monat. Als Messwert verwendet Cloudflare den Durchschnitt des täglichen Spitzenspeichers über einen Abrechnungszeitraum von 30 Tagen.

In den Gesamtspeicher fließen laufende, wartende, fehlerhafte und abgeschlossene Instanzen ein. Eine kürzere Aufbewahrung terminaler Zustände kann den Speicher abgeschlossener Instanzen senken. Den Zustand noch aktiver oder wartender Aufträge beseitigt sie jedoch nicht.

Laut aktueller Preisseite gilt die Abrechnung von Workflow-Schritten und -Speicher seit dem 10. August 2026. Die ältere Abrechnungsmitteilung vom Juli versprach lediglich, dass die Abrechnung nicht vor diesem Datum beginnen würde. Die aktuelle Seite klärt damit das veröffentlichte Startdatum, belegt aber weiterhin nicht, was auf der nächsten Rechnung eines bestimmten Kontos erscheinen wird.

Das folgende Modell ist ausdrücklich hypothetisch – weder ein Cloudflare-Benchmark noch eine zugesagte Ersparnis.

Angenommen, erfolgreiche Läufe erzeugen bei gleichbleibendem Volumen täglich 1 GB neu aufzubewahrenden Zustand. Aktive, laufende und wartende Instanzen tragen in beiden Szenarien weitere 0.5 GB-Monate bei. Um ausschließlich den Hebel der Erfolgsaufbewahrung zu betrachten, bleibt der Speicher fehlerhafter Zustände außen vor. Falls errorRetention bei 30 Tagen bleibt, muss dieser Zustand gemessen und auf beiden Seiten als identischer Posten für die Fehlerhistorie ergänzt werden.

Die modellierte Differenz beträgt $4.60. Genau deshalb müssen die Annahmen genannt werden. Ein Team mit winzigen Schrittausgaben spart womöglich fast nichts. Bei einem Workflow mit hohem Volumen und großen gespeicherten Ergebnissen kann der Posten für aufbewahrte Erfolgsläufe deutlich größer ausfallen. Der neue Standard verändert den Multiplikator, doch Zustandsgröße und Abschlussrate bestimmen die Rechnung.

Die ehrlichen Grenzen

Dreißig Tage bleiben das Maximum im Paid-Tarif. Kann ein Kunde, eine Aufsichtsbehörde oder ein monatlicher Abgleich ein Problem erst nach diesem Zeitfenster sichtbar machen, darf der Instanzzustand von Workflows nicht das einzige Archiv sein. Die minimal erforderlichen Belege gehören in ein System mit eigener Aufbewahrungs- und Zugriffsrichtlinie exportiert.

Eine längere Fehleraufbewahrung speichert zugleich mehr Fehlerzustand. Die richtige Richtlinie lautet nicht „Fehler für immer“. Sie gewährt genug Zeit, um den Vorfall zu entdecken und zu rekonstruieren, und hält anschließend einen kompakten dauerhaften Datensatz vor: etwa Instanz-ID, Workflow-Version, Zeitstempel, Status, bereinigten Fehler und das betroffene Geschäftsobjekt.

Auch eine kurze Erfolgsaufbewahrung hat eine Voraussetzung: Das erfolgreiche Ergebnis muss bereits an einem verlässlichen Ort liegen. Ist die Workflow-Ausgabe der einzige Nachweis dafür, dass eine Aktion stattgefunden hat, verringert ihre frühere Löschung sowohl den Speicherbedarf als auch die Beleglage.

Schließlich können instanzbezogene Überschreibungen die Richtlinie aufsplittern. Eine Agentur mit mehreren Erstellungspfaden kann den Dashboard-Standard korrekt setzen, während ein einzelner Aufrufer trotzdem ein anderes Zeitfenster anfordert. Die Aufbewahrung gehört in Code-Review, Betriebshandbuch und Kostenmodell – nicht nur in eine Dashboard-Einstellung.

Was jetzt zu tun ist

Noch in dieser Woche besteht Handlungsbedarf, wenn ein Paid Workflow am oder nach dem 10. September angelegt wurde, Fehler erst nach sieben Tagen bei den Verantwortlichen ankommen können oder abgeschlossener Zustand als sichtbarer Speicherposten erscheint. Erfolgs- und Fehleraufbewahrung sollten getrennt festgelegt werden.

Mit der Optimierung kann gewartet werden, wenn der Workflow noch ein Pilot mit geringem Volumen ist und sein aufbewahrter Zustand innerhalb des enthaltenen 1 GB-Monats bleibt. Die Richtlinie sollte trotzdem ausdrücklich festgelegt werden, denn das Untersuchungsfenster ist auch dann relevant, wenn der Speicheraufschlag null beträgt.

Von der Standardänderung nicht betroffen sind Workflows, die bereits vor dem 10. September existierten. Auch Workers Free bleibt bei einem Standard und einer Obergrenze von drei Tagen. In beiden Fällen ist ein externer Datensatz nötig, wenn geschäftliche Anforderungen eine Untersuchung jenseits des Plattformfensters verlangen.

Am Montag sollten sämtliche Pfade zur Erstellung neuer Workflows geprüft werden. successRetention und errorRetention sind ausdrücklich zu setzen. Anschließend lässt sich mit einem sicheren Fehlerlauf bestätigen, bis zu welchem letzten Tag der detaillierte Zustand einsehbar bleibt. Dieses Datum gehört ins Betriebshandbuch, bevor der erste echte Vorfall die Regel auf die Probe stellt.

Den nächsten praxisnahen Plattformwechsel gibt es im Newsletter.