GitHub Support Not Responding after a week after reporting GitHub IP routing defect for Chromium Builds

[duaneking]

Our github action based builds are suddenly failing - to be clear, this is a regression on GitHubs side as they worked before - due to GitHub infra routing traffic badly on its internal network after its recent changes; Google has confirmed this to us by giving us errors that show that ip's do not match expected calls and show that github has an internal issue of some kind.. but every attempt to get this working by contacting support has failed, they simply do not respond to support even though we are a company.

Google says we are using an IP that GitHub has not given us; I suspect this is a routing issue on the GitHub side. I'm happy to support Github as needed to help with this resolution but unfortunately Github has completely refused to even acknowledge any of the tickets my team has filed over the last week.

All I know is our cloud runner seems to have all its traffic being routed to the same 20.* ip as our error logs on the Google side are saying that GitHub's network is seeing and refusing, while it gives me errors and doesn't allow me to use gclient sync because its declaring that GitHub's network is not acting right... and our systems worked fine before so this is a regression!

The fact that GitHub actively ignores filed tickets needs to be looked into, as well. Its insane, and its burning credibility with my leadership and harming my efforts to get us to invest more in GitHub when GitHub promotes the idea that if something happens to a customers investment they're not going to do anything about it or even try to support it, as has been our experience so far.

[Thamidu-Peiris]

🚨 Issue Summary

Problem: GitHub Actions-based Chromium builds are failing.

Root Cause Suspected: GitHub infrastructure regression – traffic routing internally to unexpected IP ranges.

Evidence:

Builds previously worked.

Google confirms requests originate from IPs not matching expected calls, indicating an issue on GitHub’s routing side.

All traffic routes to a single 20.* IP (GitHub runner IP block).

Impact:
Build pipeline disruption.
Loss of developer productivity.
Leadership confidence in GitHub eroding due to lack of support responsiveness.

---

❌ Support Experience

Multiple tickets filed over >1 week with no acknowledgment or resolution.

GitHub has not responded despite this affecting production CI/CD systems.

Your team is willing to provide detailed error logs and support debugging, but GitHub remains unresponsive.

---

✅ Recommended Actions

1. Escalate via GitHub Account Manager or Sales Contact:
   If your organization has an Enterprise plan, escalate directly through your Customer Success Manager (CSM) or Sales Engineering contact. They can bypass normal support queues.

2. Use GitHub Premium Support or Emergency Channels:
   If you have Premium Support, raise as Severity 1 (Service Critical) to enforce SLA response times.

3. Include:

Precise failing job URLs
GitHub Actions runner IP logs (public or private)
Google error logs confirming IP mismatch
Last known working build job for regression comparison

4. Temporary Workarounds:

Self-hosted runners: Deploy in your cloud with static IPs acceptable to Google’s firewall rules to unblock builds immediately.

Network whitelist updates: If possible, update Google’s expected IPs to include the current runner IPs, but this is only viable if IPs remain stable.

5. Internal Communication

Document this clearly for leadership:

“We have encountered a GitHub infrastructure regression affecting Chromium CI builds. Multiple support requests remain unanswered for over a week. We are escalating via our account manager. As an interim measure, we are exploring self-hosted runners to restore builds while awaiting GitHub’s resolution.”

6. Future Prevention

Review critical CI/CD dependencies hosted externally and their support SLAs.

Plan for hybrid or self-hosted runners for high-criticality pipelines to mitigate third-party regressions.

---

🔔 Final Note

Your frustration is valid. GitHub should respond within SLA for production-impacting issues, especially for enterprise customers. Continuing to escalate professionally while implementing a short-term self-hosted runner workaround will keep leadership confidence stable while you await GitHub’s corrective action.

If you want, I can draft a direct escalation email to GitHub Support or your Account Manager with structured logs and severity statement. Let me know.

[duaneking]

I opt out of AI usage as AI is simply not useful or helpful for support in a trustworthy way.

I want to talk to a human, please.