Zero-Cost High Availability Using Cloudflare Workers
Published on Sat Feb 28 2026
Intro
Most people don’t think about high availability for a personal website.
But as someone building in the DevOps and Cloud space, I wanted my portfolio to reflect how I think about systems — resilient by design.
So I built automatic failover for my personal site.
Without paying for a load balancer.
Without using premium monitoring.
Without manual DNS switching.
Total cost: ₹0.
The Problem
My setup was simple:
- Primary site hosted on Netlify
- Monitoring via Better Stack
- Static fallback page on GitHub Pages
Initially, when Netlify went down, I had to:
1. Login to DNS
2. Manually change the CNAME from Netlify to GitHub Pages
3. Wait for propagation
That’s not high availability. That’s reactive ops.
The Idea
Instead of reacting to downtime…
Why not prevent users from ever seeing it?
The solution: put Cloudflare in front and let edge logic decide where traffic goes.
Architecture
Visitor
↓
Cloudflare (Edge + Worker)
↓
If Netlify healthy → Serve Netlify
If error/timeout → Serve GitHub Pages
No DNS switching.
No webhook.
No paid load balancer.
Implementation
1. Moved DNS to Cloudflare (Free plan)
2. Proxied CNAME (www → netlify.app)
3. Created a Worker
4. Attached route: <domain_name>/*
5. Implemented origin health logic
export default {
async fetch(request) {
const primary = "https://<netlify-project-url>"; # Actual Netlify Project URL
const fallback = "https://<fallback-url>"; # My Case It’s GithubPage URL
const url = new URL(request.url);
const path = url.pathname + url.search;
try {
const response = await fetch(primary + path, {
cf: { cacheTtl: 0 }
});
if (response.status >= 200 && response.status < 400) {
return response;
}
} catch (err) {}
return fetch(fallback + path);
}
}
SSL Configuration
Cloudflare SSL mode set to: Full (Strict) So the chain is:
Visitor ⇄ Cloudflare (SSL)
Cloudflare ⇄ Netlify (SSL verified)
Secure and production-grade.
Why This Is Better Than DNS Failover
- No TTL delay
- No manual intervention
- No monitoring webhook required
- Failover happens in milliseconds
- Edge-level decision making
This is how reverse proxies are meant to work.
Lessons
- You don’t need expensive infrastructure to think like an SRE.
- High availability is an architectural mindset, not a budget.
- Edge compute is incredibly powerful when used correctly.
For a personal portfolio, this is overkill. But a good Hands-on experience.