GitHub adds webhook IP ranges: delivery reliability depends on more than application code

GitHub announced three additional network ranges for webhook deliveries on github.com and added them to the hooks field of its Meta API. The additions apply across plans, including GitHub Enterprise Cloud.

The announcement is directed at a specific configuration: a receiver protected by a static network allowlist. GitHub says those operators should add the new prefixes alongside their existing webhook ranges to avoid rejecting deliveries. Operators already keeping their allowlists current through the Meta API need no additional change for these additions.

This is an update to delivery infrastructure, not an announcement that every integration has failed. It also does not establish that OrangeHat LLC or any particular customer uses a static allowlist or has missed an event.

GitHub’s Meta API documentation says the endpoint returns information including service IP addresses. It explicitly warns that values displayed in documentation are examples and that callers must query the API for current values.

That distinction creates a practical maintenance question: is the receiver using current service information, or a list copied during its initial setup? A configuration can remain unchanged while the upstream service evolves. A successful deployment of application code would not, by itself, show that an external gateway uses a current list.

For a hypothetical integration, a review note could identify the range-data source, when it was last checked and who owns the receiving network rule. Those details make the dependency reviewable. They are a proposed operating practice, not evidence that a specific environment needs a firewall change.

GitHub’s webhook guidance describes both IP allowlisting and webhook secrets. Its validation documentation says receivers should verify the signature before further processing to check that a delivery came from GitHub and was not altered.

The signature is carried in X-Hub-Signature-256 and is generated from the webhook secret and payload contents. GitHub recommends a constant-time comparison rather than ordinary equality for the validation step.

The operational implication is that admitting a connection and validating its message are different checks. Updating a source range does not replace signature validation. Conversely, correct validation code cannot process a delivery that never reaches it. Investigating one layer should preserve the other layer’s purpose rather than treating it as redundant.

GitHub recommends a 2XX response within ten seconds of receipt and suggests asynchronous queuing for work that would otherwise delay that response. It also recommends redelivering missed webhooks after a receiver recovers.

The documentation identifies X-GitHub-Delivery as a delivery identifier and notes that a requested redelivery retains the original value. That makes the identifier relevant when designing duplicate handling; a retry should not silently be treated as an unrelated new business event.

For a hypothetical missing automation, an evidence trail could ask whether the sender recorded a delivery attempt, whether the receiving edge admitted it, whether validation passed and whether processing completed. Those questions separate an unreachable endpoint from a rejected message or unfinished downstream task.

The October update gives static-allowlist operators a concrete reason to review their delivery dependency. For everyone else, it illustrates why an integration’s readiness includes the path into the application, alongside the application itself.