About
Send GitHub webhooks to Sazabi to search pushes, pull requests, issues, workflow runs, deployments, and security alerts next to the rest of your production telemetry. GitHub posts each event to your Sazabi intake URL as a JSONPOST, signed with the webhook’s secret. There is no agent to deploy, and Sazabi never calls the GitHub API.
What Sazabi records
Each GitHub delivery becomes one Sazabi record that keeps the full payload. These attributes are extracted for filtering:Prerequisites
- Admin access to the repository or organization whose webhooks you configure.
- Your Sazabi intake URL.
- A verification secret. Sazabi can generate one, or you can choose your own.
Signature verification is in early access. While it is on for your organization, Sazabi asks for the verification secret before it creates the intake URL, and rejects any delivery whose signature does not match. Contact support to turn it on.
Set up in the dashboard
1
Add the log source
In the dashboard, open Settings > Log sources, choose GitHub Webhooks and add it. If Sazabi asks for a verification secret, let it generate one or paste your own, then copy the generated secret. It is shown once.2
Add the webhook in GitHub
In the repository or organization on GitHub, go to the Webhooks page of its settings and click Add webhook.- Payload URL: Paste your Sazabi intake URL.
- Content type:
application/json. - Secret: Paste the verification secret.
- Which events would you like to trigger this webhook?: Choose the events to send, or everything.
3
Save and verify
Save the webhook. GitHub sends aping event right away; it appears under Recent Deliveries with the response Sazabi returned.Set up with the CLI
You can also register the GitHub Webhooks log source with the Sazabi CLI (installed and authenticated — see CLI reference).sazabi log-sources get <log-source-id> at any time to reprint the endpoint, or sazabi log-sources list to see every log source in the project.
Verify signatures
GitHub signs every delivery with the webhook’s secret and sends the result in theX-Hub-Signature-256 header. Sazabi checks it on the exact bytes GitHub sent and rejects a delivery whose signature does not match with 401. A rejected delivery is not stored and not billed. GitHub sends no signature for a webhook without a secret, so such a webhook is rejected too.
To change the secret later, open the log source in Settings > Log sources and choose Rotate secret. The previous secret keeps working for 24 hours by default, so GitHub keeps delivering while you update it. The Intake page shows rejected deliveries and why.
Verify
Push a commit, open an issue, or redeliver theping from the webhook’s Recent Deliveries tab. Open the Intake page in the Sazabi dashboard and confirm records from the GitHub Webhooks source appear. Records typically arrive within a minute or two.
Troubleshooting
401 in Recent Deliveries — The signature did not match. Check that the Secret in GitHub is exactly the secret Sazabi has, and that the content type is application/json. Redeliver from Recent Deliveries once fixed.
400 in Recent Deliveries — The body was not JSON. Set the webhook’s content type to application/json; the default form-encoded type is not accepted.
No records after saving — Confirm the Payload URL exactly matches your Sazabi intake URL, including the https:// scheme, and that the webhook is active and subscribed to the events you triggered.
Further reading
Intake
See per-source ingestion volume and health in the Intake page.
Webhook Events
Verify signatures and send webhooks from any other platform.
Validating webhook deliveries
GitHub’s documentation for the signature Sazabi checks.
Webhook events and payloads
Every event GitHub can send and its payload.
Log sources
Browse the full log source catalog.