GitHub-Rename bricht Cloudflare-Pages-Webhook

Ich habe einen GitHub-Account umbenannt. Eine Kosmetik-Sache, dachte ich — alter Name, neuer Name, fertig. git push lief direkt danach ohne Murren. Commits landeten im Repo. Lokal war alles grün. Die Sache war abgehakt, bevor sie überhaupt eine Sache war.

Zwei Tage später fiel mir auf, dass die Live-Seite Dinge nicht zeigte, die ich längst gepusht hatte. Kein Deploy-Fehler im Dashboard, keine Fehlermeldung, keine rote Pipeline. Die Seite war auf dem Stand des letzten Builds vor dem Rename eingefroren — zum Zeitpunkt der Entdeckung bereits fünf Tage alt.

Was wirklich passiert war

Ein Account-Rename auf GitHub ist großzügig mit Weiterleitungen. Die alten Clone-URLs antworten mit einem 301-Redirect auf die neuen. Deshalb funktionierte git push sofort weiter: Mein lokales Remote zeigte auf die alte URL, GitHub leitete um, der Push kam an. Genau dieser reibungslose Moment war die Falle — er suggerierte, dass „alles automatisch nachzieht".

Was nicht nachzieht, ist die Webhook-Zustellung. Hosting-Plattformen wie Cloudflare Pages, Vercel oder Netlify hängen ihren Auto-Deploy an einen Webhook, der bei jedem Push feuert. Dieser Webhook ist aber nicht an den Namen gebunden, sondern an die interne Repo-Identität, die bei der Verbindung registriert wurde. Nach dem Rename feuert GitHub die Events weiter — aber die Plattform-seitige Bindung passt nicht mehr sauber, und die Zustellung versandet. Der Build-Hook wird nie ausgelöst. Es gibt keinen fehlgeschlagenen Deploy, weil gar kein Deploy versucht wird.

Das ist das Heimtückische: Ein fehlgeschlagener Deploy ist sichtbar — rote Markierung, Log, Alert. Ein nicht ausgelöster Deploy ist unsichtbar. Das Dashboard zeigt den letzten erfolgreichen Build, der einfach von vor fünf Tagen ist, und nichts deutet darauf hin, dass seitdem etwas hätte passieren sollen.

Warum die Standard-Annahme falsch ist

Der Gedanke „GitHub kümmert sich um die Weiterleitung, also folgt alles" stimmt — aber nur für Clone-URLs. Für git ist der Rename transparent. Für die Event-Zustellung an Drittsysteme ist er es nicht. Die 301-Redirects decken den Pull/Push-Pfad ab, nicht den Push-löst-Webhook-löst-Deploy-Pfad.

Diese Asymmetrie ist der ganze Bug. Man sieht den einen Pfad funktionieren (git push klappt) und schließt daraus auf den anderen (Deploy läuft auch). Aber die beiden teilen sich nichts außer dem Auslöser. Der eine ist robust gegen Renames, der andere nicht.

Die 30-Sekunden-Diagnose

Was hilft, ist ein billiger externer Check, der nicht dem Dashboard glaubt, sondern die Live-Seite selbst befragt. Drei orthogonale Indikatoren, in dreißig Sekunden:

Sitemap-Datum: curl -s https://<site>/sitemap.xml | grep lastmod — steht da ein frisches Datum oder ein altes?
Build-Asset-Hash: Der Hash im Dateinamen des Haupt-Bundles (index-<hash>.js) ändert sich bei jedem Build. Bleibt er gleich, wurde nicht neu gebaut.
Content-Type/Status: curl -sI https://<site>/<datei> — antwortet die Seite überhaupt wie erwartet?

Drei verschiedene Blickwinkel, weil ein einzelner trügen kann: Ein Cache kann ein altes Asset ausliefern, eine Sitemap kann statisch sein. Wenn aber alle drei auf „alt" stehen, ist klar, dass kein Deploy mehr durchläuft.

Der eigentliche Fix war banal: im Plattform-Dashboard das Repo neu verbinden. Eine Minute Arbeit — sobald man weiß, dass es nötig ist.

Die Lektion: stille Fehler brauchen eigene Sensoren

Der teure Teil war nicht der Fix, sondern die stille Zeit davor. Zwei Tage lang glaubte ich, deployt zu haben, während nichts ankam — und die Live-Seite hing am Ende fünf Tage hinter dem Repo. Stille Fehler — die, die keinen Alarm auslösen — sind die teuersten, weil die Zeit bis zur Entdeckung allein von Zufall abhängt. Hier war es Zufall, dass mir nach zwei Tagen etwas auffiel. Es hätten auch zwei Wochen sein können.

Die verallgemeinerbare Lehre: Nach jedem Account- oder Org-Rename müssen alle Webhook-getriebenen Integrationen — Hosting, CI, Bots — bewusst neu verbunden werden. Und für alles, was „eigentlich automatisch" passieren soll, lohnt sich ein billiger Indikator, der das Ergebnis von außen prüft, statt der internen Statusanzeige zu vertrauen. Ein Dashboard, das sagt „letzter Build erfolgreich", beantwortet nicht die Frage „ist der aktuelle Stand live".

Was offen ist

Der manuelle 30-Sekunden-Check ist gut für den akuten Fall, aber er ist eben manuell — er hilft nur, wenn man ihn ausführt. Die saubere Lösung wäre eine kleine Deploy-Freshness-Probe im Monitoring: ein periodischer Abgleich zwischen dem letzten Commit-Datum und dem Sitemap-/Asset-Stand der Live-Seite, der Alarm schlägt, wenn beide zu weit auseinanderlaufen. Bis das steht, bleibt die Konvention: nach jedem Rename die Hosting-Bindungen anfassen, nicht darauf vertrauen, dass git push genügt.

„Erledigte" Infrastruktur-Schritte holen einen später ein — meist ohne jeden Alarm. Wenn dich so ein stiller Bruch auch schon erwischt hat, schreib mir.