Six static sites vanished overnight: the 60-minute triage that separates DNS drama from account-level failure

2026-04-10 · Code Pipelines

Picture it: every public site you run on GitHub Pages goes dark at the same time.

You refresh. You check the registrar. You wonder if that last push broke the build. Then you run the site locally and it is perfect—which tells you something important before you burn another afternoon on GitHub Pages custom domain rabbit holes.

Below is the decision tree we wish we had on hour zero: how to tell github pages not loading because of DNS, versus a platform or GitHub account suspended scenario that quietly takes publishing offline while your repo still clones. Then we cover a practical static site disaster recovery stack: second remote, second host, DNS discipline, and monitoring so “all my sites down” does not equal “we had no signal until users complained.”

Disclaimer: suspension reasons vary by case. This is operational guidance, not legal advice. When in doubt, work with GitHub Support and your own counsel.

Why local can lie to you (and why that is good news)

Local preview only proves your files parse and your assets resolve on your machine. It does not prove DNS is correct, TLS is provisioned, or that the account that owns the Pages pipeline can still publish.

GitHub Pages is not “magic FTP.” It is hosting tied to GitHub identity, repository settings, and platform policy. When the account or org behind those settings is restricted, you can still have a clean working tree locally while the public edge that served username.github.io or your apex domain stops answering the way you expect. That is the mechanism: separate source of truth (git) from delivery (Pages, DNS, TLS).

The 60-minute triage: work this list in order

Do not shuffle these steps. Order matters because the cheap checks catch the majority of real outages.

1. Confirm scope. Is it one custom domain or every property? If everything on Pages died together, skip straight to account and auth checks after a quick DNS sanity pass.
2. DNS and propagation. For each custom domain, verify A/AAAA/CNAME records against GitHub’s current Pages documentation. Check TTL: a recent change can look like a mystery failure for hours. Use a DNS checker from multiple regions.
3. Strip the custom domain variable. Hit the raw *.github.io host (or the Pages default URL) directly. If the default URL is dead too, you are not looking at a lone registrar typo.
4. HTTPS and certificate state. Certificate renewal issues can present as “site down” in browsers. Note the error string; “certificate problem” versus “connection refused” points to different buckets.
5. Git auth and integrations. If a host suddenly cannot connect to GitHub to pull your repo, read the error literally. OAuth revocation, organization SSO changes, or IP allow lists can masquerade as “the integration is broken.” That pattern often shows up before you get a clear banner in the UI.
6. Account notices. Check email and on-site notifications. GitHub may flag activity for manual review under abuse-detection or Terms of Service workflows. Support may ask a plain question—for example, how you plan to use GitHub—while they review. Reply briefly and factually: project types, whether repos are personal or org-owned, and that you are using Pages for static sites.

ASCII triage flow you can paste in a runbook:

Sites unreachable
  → Local preview works? (usually yes)
  → Fix DNS / TTL / registrar first?
  → Default github.io URL still bad?
       → Suspect publishing pipeline or account restriction
  → Integrations cannot auth to GitHub?
       → Policy / token / OAuth / org settings
  → Open ticket; parallelize failover if revenue or SLA is on the line

When it is not DNS: what account-level friction can break Pages

Platforms apply automated signals plus human review. Outcomes differ: temporary limits, requests for information, or suspension until resolved. Public documentation and community threads describe a range of experiences; your timeline will not match everyone else’s.

What is consistent operationally: if publishing or integration depends on a restricted identity, your GitHub Pages sites may be unavailable even when you can still clone or export repositories. That is why a migrate GitHub to GitLab (or another remote) plus a second deploy target is not paranoia—it is production hygiene for static portfolios and docs you care about.

Failover we actually shipped: GitLab + Cloudflare Pages + DNS moves

When Pages is the bottleneck, the fastest path back online is: get a clean copy of the repo, push to a second forge, point a static host at that forge, then update DNS at your registrar (whether that is GoDaddy, Namecheap, or another).

GitLab (or Bitbucket, Codeberg, etc.) as a second remote gives you a publishing identity that is not coupled to the same account flag. Cloudflare Pages (or Netlify, Vercel for static) gives you a deploy surface that connects to that new remote. Expect friction: you will touch apex records, www CNAMEs, and maybe TLS settings—so schedule changes when you can tolerate a short cutover window, and lower TTLs ahead of time next time.

This is the core of cloudflare pages vs github pages thinking for resilience: not “which is cooler,” but “which two can you route between when one control plane is unavailable?”

Backup plan: the stack that survives a bad Tuesday

• Git remotes: Keep origin on GitHub if you like, but add gitlab (or another) and push main regularly. Occasionally archive a git bundle or tarball to cold storage so you are not 100% dependent on any single host’s UI.
• Two deploy paths: Document how to cut from Pages to Cloudflare Pages or Netlify in one page of notes: build command, output directory, env vars (if any), and branch. Static sites are ideal for this because the surface area is small.
• DNS: Export zone files from the registrar, store them offline, and avoid “DNS only lives in my head.” Before risky changes, drop TTL temporarily so rollback is faster.
• Monitoring: External uptime checks on each apex and www, with alerts that hit email or SMS. Your laptop is not a monitoring platform.
• VPS optional mirror: For teams that want a dumb-reliable origin, a tiny VPS plus object storage or a static sync is old school but robust. See Vultr or DigitalOcean if you want a low-cost node you control end to end.

Pick your host: when each option is enough

FAQ-style searches (plain answers)

Why is GitHub Pages not loading but my repo looks fine? Often DNS, custom domain configuration, or TLS. If default Pages URLs fail too, look past the registrar.

Can a GitHub account suspension take down Pages? Publishing can depend on account standing; treat total multi-site failure as a signal to verify account status and support channels, not only DNS.

Is migrate GitHub to GitLab hard? For static sites, usually no: push remotes, reconnect CI or Pages-equivalent, update DNS. The tedious part is multi-domain DNS and retesting TLS.

Do this week: direct checklist

1. Add a second remote and push main.
2. Write a one-page failover doc with build output path and DNS records.
3. Turn on external uptime monitoring for every production hostname.
4. Export DNS zone files and store them somewhere boring and safe.
5. Run a 30-minute tabletop: “GitHub integration offline—what do we click next?”

Related: Best hosting for developers 2026, Deploy AI apps to production, Security-first CI/CD 2026.