A deployment integration goes quiet, but the application still looks healthy. Before changing application code, check whether a GitHub webhook reached your network at all. GitHub’s October 29 update adds webhook delivery IP ranges, making this a useful moment to review static allowlists and the evidence you keep when a delivery fails.
Quick answer: If you filter incoming GitHub webhooks by source address, compare your rules with the current Meta API hooks list. Then diagnose delivery, signature validation and downstream processing separately. Updating a network rule alone does not prove that a missed deployment or notification was recovered.
What changed in GitHub webhook IP ranges?
The October 29 GitHub announcement identifies three additional CIDR prefixes for webhook deliveries on github.com: 9.234.98.160/28, 9.234.98.176/28 and 9.234.106.48/28. They supplement existing ranges and apply across github.com plans, including GitHub Enterprise Cloud. GitHub says teams already keeping their allowlist current through the Meta API need no changes for these additions.
For a manually maintained rule set, treat the announcement as a prompt to compare configurations. For a synchronized rule set, inspect its latest successful run. Neither situation calls for replacing your entire firewall configuration with three addresses copied from a news story.
Capture evidence before changing rules
Start with one expected event and its approximate time. Write down which repository or application produced it, which receiver should handle it and what business result you expected. For example, a release event may be expected to update an internal deployment dashboard. That expectation gives the investigation a concrete finish line.
GitHub’s webhook troubleshooting guide recommends checking recent deliveries and server logs. It distinguishes connection problems, response timeouts, certificate problems and signature failures. A failed connection is a reason to inspect networking; it is not evidence that a payload parser is broken. An HTTP response from the receiver gives you a different starting point.
Our suggested incident note has four entries: event expected, GitHub delivery result, receiver observation and downstream result. Keep tokens, webhook secrets and sensitive payload fields out of shared notes. Record timestamps and references to access-controlled logs instead of pasting entire requests into chat.
Review the live allowlist with a rollback plan
The Meta API documentation identifies GET https://api.github.com/meta as the source of GitHub network metadata. Its response includes hooks. Documentation response values are examples; query the live API when planning a real update.
Use your existing approved network-management process. Save the current configuration, retrieve a fresh response, validate that it contains a plausible nonempty hooks list and review differences before applying them. If retrieval or parsing fails, stop the change rather than turning incomplete output into a replacement policy. These are proposed operational safeguards, not a claim that we tested your infrastructure.
Assign one owner to the rule change and another explicit check to the receiver. Note which network layer owns the restriction: an edge firewall, load balancer, reverse proxy or application rule. A correct change in the wrong layer leaves the real failure untouched. Avoid widening unrelated routes merely to make a test pass.
Keep delivery validation separate from network filtering
GitHub’s webhook best practices recommend HTTPS, webhook secrets, periodic allowlist updates where filtering is used and checking event types and actions. A permitted source address is not a replacement for validating a delivery. Preserve those controls while reviewing network access.
For recovery work, map three separate observations: the request arrived, the receiver accepted it and the intended action finished. Label an unobserved stage as unknown. This small distinction prevents a successful HTTP response from becoming an unsupported claim that a release, notification or database update completed.
Recover missed events deliberately
According to GitHub’s failed-delivery documentation, failed webhooks are not automatically redelivered. Manual redelivery or a deliberately implemented recovery process is therefore a separate task after fixing the original problem.
Before requesting a replay, inspect whether the original event already caused a partial side effect. Ask the receiver owner how duplicate processing is handled. Choose a low-risk event to verify first, record the observed outcome and expand recovery only after that result is understood. An indiscriminate replay of deployment or notification events can create work you did not intend.
Retain the final incident note alongside your release records. Our release-evidence checklist explains why keeping useful evidence deserves its own plan. For this incident, a compact record of what failed, what changed and what was actually recovered is more valuable than a screenshot of a green status alone.
A practical close-out checklist
- Confirm the applicable github.com webhook source ranges were reviewed against a fresh API response.
- Record the changed rule layer, change owner and rollback location.
- Verify that expected deliveries reach the receiver without weakening signature checks.
- Identify missed events and assess duplicate side effects before recovery.
- Confirm the downstream result, then assign ongoing monitoring to an owner.
The useful outcome is an explained, repeatable recovery path. Keep unresolved stages visible; do not close the incident solely because the network configuration now matches a published list.
Editorial disclosure: This source-based guide was prepared with AI assistance and checked against the linked primary sources on November 2, 2026. TechPulse did not run a webhook, firewall, replay or production-infrastructure test for this article. The recovery worksheet and rollout suggestions are editorial analysis, not measured results. See our editorial policy.
✍️ Leave a Comment