Source: Dev.to

You just containerized your static site (HTML, CSS, JS) using an nginx:alpine image. You deployed it to Kubernetes. It works locally. Then you get the page flip: 502 Bad Gateway or random Connection Refused errors during a rolling update. Why? Because Kubernetes thinks your container is “alive” and “ready” simply because the Nginx process is running—even if the configuration is broken, the disk is full, or the site is compiling. Let’s fix that. Here is the only guide you need for liveness and readiness probes on static sites. The Golden Rule of Static Sites Readiness: “Can I send traffic to this Pod right now?” (Startup & reloads) Liveness: “Is the Pod broken beyond repair?” (Hard crashes) For a static site, we use Readiness for startup delays and Liveness for deadlocks. The Naive Approach (Don’t do this) yaml Slow Builds: If you use a sidecar or initContainer to fetch a huge static bundle, the probe starts failing immediately. Kubernetes kills your pod before it finishes downloading. 404s happen: What if your app serves a 200 OK for /, but your CSS bundle main.css is corrupted? The pod is “alive” but the site is broken. The Correct Setup: Two Probes, One Health Endpoint If you’re using Nginx (the static site king), add this to your nginx.conf: nginx location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; }

Health check endpoint

location /health { access_log off; return 200 “healthy\n”; add_header Content-Type text/plain; }

} Step 2: Configuring the Readiness Probe (The “Slow Starter”) yaml Step 3: Configuring the Liveness Probe (The “Zombie Killer”) Important: The liveness probe should be more conservative than readiness. You don’t want Kubernetes restarting your pod during a brief, heavy load spike. yaml yaml apiVersion: v1 yaml Common Static Site Pitfalls For 99% of static sites, a basic httpGet on a custom /health endpoint is all you need. Don’t overcomplicate it with exec commands or TCP probes. What’s your static site horror story? Let me know in the comments. 🚀