Een gemiste push-webhook is een gemiste deploy. Niet leuk.
GitHub stuurt webhooks bij elke push, pull request, release, issue en discussion. CI/CD-pipelines en deploy-systemen vertrouwen daarop. Als je server het event mist, draait je pipeline niet — en dat merk je vaak pas wanneer iemand vraagt waar zijn change blijft. WebhookFlow zorgt dat elke GitHub-event aankomt.
Waarom GitHub-webhooks vragen om extra zorg
Hoog volume bij actieve repositories
Een actieve open-source repository of een drukke monorepo kan honderden events per dag genereren — vooral bij pushes naar feature-branches en check-runs van CI. Eén kortdurende storing bij jouw kant en je mist tientallen events.
GitHub probeert niet eeuwig opnieuw
Mislukt een delivery, dan probeert GitHub het een paar keer met toenemende intervallen. Daarna stopt het. Geen automatische compensatie als jouw server een halve dag offline was tijdens een release-window.
Signature-validatie via HMAC
GitHub ondertekent webhooks met HMAC-SHA256. Verkeerd ingestelde secret of verschil in body-encoding leidt tot afgewezen events — vaak stilletjes, zonder duidelijke foutmelding voor jouw kant.
Wat WebhookFlow specifiek voor GitHub doet
Direct accepteren, jouw pipeline rustig voeden
WebhookFlow geeft GitHub binnen milliseconden 200 terug. Daarna sturen we het event door naar jouw CI/CD-systeem of deploy-controller in een tempo dat het aankan. Geen overlopende queue, geen verloren push.
Persistente retries bij downtime
Is jouw runner of orchestrator even niet bereikbaar? WebhookFlow houdt de events vast en probeert het urenlang opnieuw. Zodra jouw kant terug is, krijgt het systeem alle gemiste push- en release-events in volgorde.
HMAC-validatie centraal
Configureer je GitHub webhook secret eenmalig in WebhookFlow. Wij valideren elke incoming request volgens de GitHub-spec en weigeren mismatches voor ze jouw infrastructuur bereiken.
Filteren op event-type
GitHub stuurt veel event-types naar één URL. Met WebhookFlow stuur je alleen "push" door naar je deploy-systeem en "issues" of "discussion" naar je notificatie-dienst. Geen filterlogica meer in je applicatie.
Veelgestelde vragen over GitHub-webhooks
Werkt dit met repository én organization webhooks?
Ja. WebhookFlow accepteert webhooks vanuit elk niveau — single repository, organization-wide of GitHub App. Configuratie is identiek: zet de payload-URL op het WebhookFlow-endpoint en kopieer de secret.
Kan ik webhook deliveries opnieuw afspelen?
Ja. GitHub biedt zelf een "Redeliver"-knop in de webhook-instellingen, maar dat scaled niet bij honderden events. In WebhookFlow zie je per event of het is doorgegeven en welke respons jouw server gaf — opnieuw versturen met één klik, of geautomatiseerd via API.
Is dit overkill voor een hobbyproject?
Voor een hobby-CI op één repository is dit waarschijnlijk overkill. Voor een team dat afhankelijk is van CI-snelheid en deploy-betrouwbaarheid, of voor een SaaS-platform dat customer-GitHub-events verwerkt, telt elke gemiste event.
Hoe stel ik het in vanuit GitHub?
In je repository of organization settings ga je naar Webhooks, voegt een nieuwe webhook toe met de WebhookFlow-URL en jouw secret. Selecteer de events die je wil ontvangen (of alles met "Send me everything"). Vanaf dat moment loopt elke aanroep via WebhookFlow.
Mis nooit meer een push-event
WebhookFlow is in ontwikkeling en zoekt beta-gebruikers. Meld je aan voor vroege toegang.