Ein korrigierter Code ist noch keine veröffentlichte Änderung. Ein KI-Agent kann über Nacht Dateien bearbeiten, Prüfungen bestehen und alles speichern. Wenn die Veröffentlichung hängt, sehen Besucher trotzdem die gestrige Version.
1. „Erledigt“ steht im Bericht, aber nicht auf der Website
Vor dem Schlafengehen beauftragst du ein neues Design, Werbeplätze und fremdsprachige Seiten. Morgens meldet die KI: Änderungen erstellt, Tests bestanden, Dateien gespeichert.
Du öffnest die Website. Der alte Knopf sitzt noch an derselben Stelle. Die KI hatte Nachtschicht, die Website hat verschlafen.
Vier Schritte müssen getrennt werden: erstellen, speichern, veröffentlichen und die öffentliche Seite prüfen. Erst der letzte Schritt zeigt, dass die Änderung wirklich angekommen ist.
2. Das Lager ist voll, aber die Laderampe gesperrt
Ein Quellcode-Repository bewahrt Änderungen auf. Ein Auslieferungssystem bringt sie ins Netz. Beide können unabhängig voneinander ausfallen. Neue Artikel und eine neue Version des Website-Programms laufen außerdem manchmal über getrennte Wege.
So entstehen widersprüchliche Zustände: Neue Beiträge erscheinen, das Design bleibt alt. Tausende übersetzte Texte warten auf die Veröffentlichung. Die Werbung wurde im Code aktualisiert, ist aber online unsichtbar.
Eine einzige blockierte Ausfahrt kann eine ganze Fabrik voller fertiger Arbeit aufhalten.
3. Zwei kostenlose Kontingente, zwei unterschiedliche Baustellen
Im Oktober 2026 umfasst der kostenlose Cloudflare-Tarif monatlich 3.000 Build-Minuten für Workers Builds und täglich 100.000 Anfragen für Workers.[1][2]
Das erste Limit betrifft das Erstellen und Ausliefern einer neuen Softwareversion. Das zweite betrifft Anfragen an das laufende Programm. Beides kann aufgebraucht sein, doch die Gegenmaßnahmen unterscheiden sich.
Bei fehlenden Build-Minuten hilft es, unnötige Wiederholungen zu vermeiden und erlaubte Ersatzwege vorzubereiten. Bei zu vielen Anfragen sollten statische Dateien möglichst seltener durch den Worker laufen. Ein reparierter Herd verkürzt nicht automatisch die Schlange vor dem Restaurant.
4. Mit jedem neuen Versuch wird nur der Fehlerbericht länger
Ein Build scheitert. Ohne die Ursache zu prüfen, startet jemand ihn erneut. Wieder ein Fehler. Das Monatskontingent schmilzt.
Zehn Fehlermeldungen, null veröffentlichte Verbesserungen. Herzlichen Glückwunsch zur neuen Fehlerbericht-Druckerei.
Besser: Protokoll lesen, den Fehler wenn möglich lokal nachstellen, die Ursache beheben und erst dann einen weiteren Lauf starten. Eine einzelne Textänderung muss nicht zwingend einen vollständigen Neuaufbau der Website auslösen. Unabhängige, sichere Veröffentlichungen sollten weiterlaufen können.
5. Ein guter KI-Agent übernimmt auch die Wiederherstellung
Sein Bericht sollte sauber trennen: Was ist live? Was hängt noch? Warum? Was konnte parallel weitergehen? Innerhalb seiner Berechtigungen kann der Agent Fehler untersuchen und die Auslieferung selbst zu Ende bringen.
Mehrere Veröffentlichungsdienste schaffen Ausfallsicherheit, brauchen aber einen gemeinsamen Stand der aktuellen Version. Sonst überschreibt ein Dienst die neue Fassung mit einer alten. Geheimnisse und Kontofreigaben bleiben beim Kontoinhaber.
Der letzte Beleg ist die geöffnete öffentliche Seite mit dem tatsächlich sichtbaren Ergebnis.
6. Eine sinnvollere Bilanz am Morgen
Entscheidend sind die für Besucher sichtbaren Änderungen, behobene Fehlläufe und vermiedene Wiederholungsfehler. Die Zahl bearbeiteter Dateien allein sagt wenig aus.
Der Mensch hat Ideen und schläft. Die KI korrigiert, repariert, veröffentlicht und kontrolliert.
Die beste Guten-Morgen-Nachricht lautet nicht „Ich habe viel gearbeitet“.
Sondern: „Die neue Version ist jetzt wirklich online.“
Quellen (2)
[1] Cloudflare, "Limits & pricing — Workers Builds" (checked 2026-10-15): https://developers.cloudflare.com/workers/ci-cd/builds/limits-and-pricing/
[2] Cloudflare, "Limits — Workers", last updated 2026-10-12 (checked 2026-10-15): https://developers.cloudflare.com/workers/platform/limits/
