GitHub’s October 29, 2026 changelog adds three IPv4 ranges for webhook deliveries on github.com. Operators maintaining a static source-IP allowlist should read them as additions alongside existing webhook ranges, rather than a complete replacement list.
What the announcement lists
- 9.234.98.160/28
- 9.234.98.176/28
- 9.234.106.48/28
GitHub says the additions appear in the Meta API’s hooks field and apply across github.com plans, including GitHub Enterprise Cloud. The announcement says an allowlist already kept current through the Meta API needs no changes for these additions. That qualification matters: having an update script is different from confirming its last successful result.
Use current data rather than a documentation example
The REST reference identifies GET /meta as the source of GitHub meta information. It explicitly warns that response values printed in the documentation are examples and that callers must query the API directly for the latest values. For webhook delivery ranges, use the hooks field identified by the announcement; do not substitute another service’s field.
Before changing a rule, make a review record containing the source endpoint, retrieval time, selected field and proposed difference from the existing configuration. Confirm that the response was successfully retrieved and parsed. An unreadable response should become an unresolved check, not an invented conclusion that GitHub intentionally supplied an empty list.
Separate network admission from payload validation
GitHub’s webhook best practices recommend periodically updating IP allowlists because addresses can change. The same guide separately recommends a webhook secret to validate deliveries and HTTPS with SSL certificate verification enabled. Updating a network rule does not perform those other checks.
For an evaluation you control, write down the expected outcome before testing: the network accepts an intended delivery, the receiver validates it, and the application processes the intended event. Record each observation separately. A network rule accepting a request does not, by itself, demonstrate the application processed the right event.
Follow up on failed deliveries
The best-practices guide recommends redelivering missed webhooks after a server recovers. It also notes that a redelivery carries the same X-GitHub-Delivery value as its original delivery. Account for that when inspecting receiver behavior; a repeated delivery should not be mistaken for proof of a new underlying event.
Keep the configuration change and delivery outcome in the same review record, with their respective times. If delivery still fails, preserve the returned error and investigate that evidence rather than assuming the IP update explains every failure. No firewall, receiver, live Meta API response or webhook delivery was tested for this article.
Primary sources
- GitHub changelog, October 29, 2026: https://github.blog/changelog/2026-10-29-webhook-ip-ranges-added-to-the-meta-api/
- GitHub REST API — meta information: https://docs.github.com/en/rest/meta/meta
- GitHub webhook best practices: https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks
Check the allowlist review
