GitHub Webhooks: erstellen, prüfen und erneut senden
GitHub Webhooks
GitHub Webhooks: Einrichtung, Events und Signaturprüfung | We.Inc
GitHub Webhook erstellen, Events wählen, den Header X-Hub-Signature-256 mit funktionierendem Code prüfen und fehlgeschlagene Zustellungen erneut senden. Mit Signatur-Checker im Browser.
Ein GitHub Webhook ist eine Nachricht, die GitHub an die URL deines Servers sendet, sobald in einem Repository etwas passiert, etwa ein Push, ein neues Issue oder ein Release. Du fügst ihn im Repository unter Settings, Webhooks hinzu. Lege ein Secret fest, damit du den Header X-Hub-Signature-256 prüfen und gefälschte Zustellungen ablehnen kannst.
Wissenswertes zu GitHub Webhooks (docs.github.com, Oktober 2026)
Punkt
Was GitHub dokumentiert
Signatur-Header
X-Hub-Signature-256, Wert beginnt mit sha256=
Signaturverfahren
HMAC-Hex-Digest mit SHA-256, dein Secret als Schlüssel
Antwortzeit
Über 10 Sekunden wird als fehlgeschlagene Zustellung gewertet
Automatische Wiederholungen
Keine; fehlgeschlagene Zustellungen werden nicht automatisch erneut gesendet
Manuelles erneutes Senden
Zustellungen der letzten 3 Tage
Maximale Payload-Größe
25 MB; größere Payloads werden nicht zugestellt
Mit Webhooks informiert GitHub deine Website oder App über Änderungen genau in dem Moment, in dem sie passieren. So kannst du bei jedem Push eine Website neu bauen, eine Nachricht posten, wenn ein Issue eröffnet wird, oder bei einem Release ein Changelog aktualisieren. Den wichtigen Teil überspringen die meisten Kurzanleitungen: zu prüfen, ob eine Zustellung wirklich von GitHub kommt. Der Checker unten berechnet direkt in deinem Browser dieselbe Signatur, die GitHub sendet.
Öffne das Repository, klicke auf Settings, dann in der linken Seitenleiste auf Webhooks und dann auf Add webhook.
Trag deinen Endpoint unter Payload URL ein und wähle application/json als Content-Type, damit der Body als reines JSON ankommt.
Gib unter Secret eine lange Zufallszeichenfolge ein und hinterlege denselben Wert in den Umgebungsvariablen deines Servers.
Wähle unter Which events would you like to trigger this webhook nur das push-Event oder einzelne Events aus, setze das Häkchen bei Active und speichere.
GitHub sendet sofort ein ping-Event; prüfe es unter Recent Deliveries, um zu bestätigen, dass dein Server geantwortet hat.
Antworte schnell. Gib sofort einen 2xx-Status zurück und erledige langsame Arbeit danach in einem Hintergrundjob, denn eine Antwort nach mehr als 10 Sekunden gilt als Fehlschlag.
Berechne die Signatur über die rohen Bytes des Bodys, bevor du JSON parst. Parsen und erneutes Serialisieren verändert die Bytes, und die Prüfung schlägt fehl.
Vergleiche Signaturen mit einer Funktion mit konstanter Laufzeit wie crypto.timingSafeEqual, niemals mit einem einfachen ==.
Nutze X-GitHub-Delivery, eine eindeutige ID pro Zustellung, um Duplikate zu überspringen, wenn du von Hand erneut sendest.
Abonniere nur die Events, die du verarbeitest. Weniger Events bedeuten weniger Anfragen an deinen Server und weniger, das du absichern musst.
Häufige Fragen
Wiederholt GitHub fehlgeschlagene Webhooks?
Nein. Laut GitHub-Dokumentation werden fehlgeschlagene Zustellungen nicht automatisch erneut gesendet. Du kannst Zustellungen der letzten 3 Tage unter Recent Deliveries von Hand erneut senden.
Was ist der Header X-Hub-Signature-256?
Er wird gesendet, wenn der Webhook ein Secret hat. GitHub nimmt den Request-Body, berechnet einen HMAC mit SHA-256 und deinem Secret als Schlüssel und sendet das Hex-Ergebnis mit dem Präfix sha256=. Dein Server wiederholt die Berechnung und vergleicht.
Welche Events kann ein Webhook empfangen?
Viele, darunter push, pull_request, issues, release und workflow_run. Der Header X-GitHub-Event nennt das Event, das die jeweilige Zustellung ausgelöst hat, und ping kommt an, wenn du den Hook zum ersten Mal anlegst.
Kann ich einen Webhook ohne öffentlichen Server testen?
Dein Endpoint muss aus dem Internet erreichbar sein, denn GitHub sendet dorthin. Für die lokale Entwicklung nutzt du ein Tunneling-Tool, das deinem Rechner eine temporäre öffentliche URL gibt, und trägst diese als Payload URL ein.
Webhook oder API-Polling?
Ein Webhook schickt dir jede Änderung, sobald sie passiert; Polling heißt, die API in festen Abständen abzufragen. Webhooks brauchen weniger Anfragen und kommen schneller an. Das zählt, weil API-Aufrufe auf die Rate Limits angerechnet werden.
Was mit jeder Zustellung ankommt
Jede Zustellung ist ein POST mit Headern, die sie beschreiben: X-GitHub-Event nennt das Event, X-GitHub-Delivery ist eine eindeutige ID, X-GitHub-Hook-ID identifiziert den Webhook, und der User-Agent beginnt immer mit GitHub-Hookshot/.
Der Body ist die Event-Payload. Bei einem Push listet sie die Commits und die Branch-Referenz auf, sodass ein Deploy-Skript Pushes auf andere Branches als den, den es baut, ignorieren kann.
Deinen Prüfcode mit GitHubs Testwerten abgleichen
GitHub veröffentlicht eine bekannte Eingabe, damit du vor dem Livegang beweisen kannst, dass dein Code stimmt: Das Secret It's a Secret to Everybody und die Payload Hello, World! sollten eine Signatur ergeben, die mit 757107ea beginnt.
Der Checker auf dieser Seite ist mit diesen Werten vorausgefüllt. Wenn dein Server daraus dasselbe Ergebnis berechnet, ist dein Prüfcode korrekt.
Diese Express-Route liest den rohen Body, berechnet den HMAC mit deinem Secret und vergleicht ihn mit konstanter Laufzeit, bevor sie der Payload vertraut.
express.raw behält genau die Bytes, die GitHub signiert hat. Das Secret kommt aus einer Umgebungsvariable, nie aus dem Code.
Zustellungs-Header
Header bei jeder GitHub-Webhook-Zustellung
Header
Was er enthält
X-GitHub-Event
Den Namen des Events, etwa push oder issues
X-GitHub-Delivery
Eine eindeutige ID (GUID) für diese Zustellung
X-GitHub-Hook-ID
Die ID des Webhooks, der sie gesendet hat
X-Hub-Signature-256
sha256= plus den HMAC des Bodys, nur wenn ein Secret gesetzt ist
User-Agent
Beginnt immer mit GitHub-Hookshot/
Webhook-Signatur-Checker
Gib ein Secret und einen rohen Request-Body ein, um den Wert für X-Hub-Signature-256 zu sehen, den GitHub senden würde. Läuft in deinem Browser mit der Web Crypto API; nichts wird hochgeladen.
Webhook-Secret
Roher Request-Body
Empfangener Signatur-Header (optional)
sha256=...
Berechnete Signatur
Treffer: Die Signatur dieser Zustellung ist für dieses Secret und diesen Body gültig.
Kein Treffer: Secret, Body-Bytes oder Header weichen ab.
GitHubs Testwerte laden
Mit GitHubs Testwerten sollte das Ergebnis lauten: