KUBERNETES ROLLOUT SAFETY CHECK · RUNS IN YOUR BROWSER

Will your Kubernetes rollout drop live requests?

RollingUpdate promises that Kubernetes replaces pods gradually. It does not promise that a pod is ready before traffic reaches it, or that it has stopped receiving traffic before it shuts down. Those two gaps are why a deploy that reports success can still serve a burst of connection errors — and nothing in kubectl rollout status will ever mention it. Paste your Deployment YAML below.

Nothing is uploaded. The manifest you paste is parsed in this browser and never leaves your device; this tool makes no network calls of its own and never touches your cluster.

1. Paste your manifests

A Deployment, and ideally the PodDisruptionBudget and Service that select it. Multiple documents separated by --- are fine, and a kind: List wrapper is unwrapped — so the whole output of kubectl get deploy,pdb,svc -o yaml works, as does a rendered Helm or Kustomize template. Including the Service is worth it: without one, nothing in the manifest says which container answers a request, so every container is checked and a sidecar will show up alongside your application.

Paste a Deployment above and click Check.

Prefer a CLI, or want this as a CI gate?

Same engine, zero dependencies, no cluster access:

node check.mjs                     # scan every .yaml under the current directory
node check.mjs k8s/production      # scan one directory or one file
node check.mjs --format json       # machine-readable
node check.mjs --list-checks       # exactly what is checked, and at what severity
node check.mjs --fail-on-risk      # exit 2 if a rollout can drop requests

Save the three files this page itself runs on — check.mjs, engine.mjs and yaml.mjs — into one directory. Node's standard library only, nothing to install, no network calls, no kubeconfig. Render your Helm chart or Kustomize overlay first (helm template / kubectl kustomize) and pipe the output to a file, then wire --fail-on-risk into CI so a newly-added Deployment without a readinessProbe is caught before it merges.

What it checks

The whole list — there is nothing hidden behind it.

Common questions

My rollout says zero downtime. Why would it drop requests?

Because "RollingUpdate" only promises that Kubernetes replaces pods gradually. It does not promise that a pod is ready before it receives traffic, or that it has stopped receiving traffic before it shuts down. Without a readinessProbe, a pod joins the load balancer the instant its process starts — every request arriving before the app has booted gets an error. Without a preStop delay, the container can exit before the pod's removal has propagated to every kube-proxy and ingress controller, so proxies keep sending it connections that are then refused. Both are invisible in a rollout that reports success.

Why does a missing preStop hook matter if my app handles SIGTERM?

Because handling SIGTERM correctly is not the problem. When a pod is deleted, two things start at the same moment and neither waits for the other: the kubelet sends SIGTERM, and the endpoints controller begins removing the pod from EndpointSlice. That removal has to reach every kube-proxy and every ingress controller before they stop routing to it, and that propagation is not instant. A perfectly behaved app that shuts down promptly on SIGTERM can therefore be gone while proxies are still sending it new connections. A preStop hook that does nothing but wait gives the removal time to land before shutdown begins.

Does a clean result mean my deploy is zero-downtime?

No. This checks a specific, named list of manifest-level configurations — you can see the whole list with --list-checks, and there is nothing hidden behind it. It cannot know how long your application takes to drain a connection, whether your readinessProbe actually tests the dependencies a real request needs, whether your ingress controller honours EndpointSlice updates promptly, or whether a database migration in the same release is backwards compatible. A clean result means these checks found nothing; it is not a guarantee about your deploy.

Does this tool connect to my cluster?

No, and it has no way to. It reads YAML text and nothing else — no kubeconfig, no credentials, no API server, no network calls at all. The browser page parses what you paste on your own device, and the CLI reads files from your own disk. That is what makes it safe to run against production manifests in CI without granting it any cluster access, because there is none to grant.

What about StatefulSets, DaemonSets and Argo Rollouts?

Only Deployment and PodDisruptionBudget are judged, and a Service is read (not judged) to work out which container receives traffic. Other kinds are listed as skipped rather than silently ignored, so you can see what was not looked at. StatefulSet and DaemonSet rollouts have genuinely different ordering semantics, and reporting Deployment rules against them would produce confident wrong answers — which is worse than abstaining.

Why is the default maxUnavailable of 25% not flagged?

Because at most replica counts it is safe. Kubernetes rounds maxUnavailable down and maxSurge up, so at 3 replicas the 25%/25% default resolves to maxUnavailable 0 and maxSurge 1 — a new pod starts and becomes ready before any old pod is removed. Flagging that would make the tool cry wolf on the majority of real manifests. It is reported only when the resolved number actually reaches the replica count, which is when every pod really can be down at once.

More: why your Kubernetes rollout drops requests. Already run kube-score? See how this checker compares on the rollout question specifically. This checks whether a rollout is safe, not whether the manifest's apiVersion itself will survive the next Kubernetes upgrade — a manifest can pass every check here and still fail to apply outright on a newer cluster. See Kubernetes Deprecated API Check for that, a separate failure class entirely.