▚ xentropy
← All posts
Jan Pruszynski

You pushed. The pods didn't pull.

The deploy said success. Production ran old code for forty minutes. The same-tag push is the most boring outage generator in Kubernetes — here's the prompt that catches it.

There's a special kind of confusion that only happens after a successful deploy. The pipeline is green. The image pushed. The rollout command exited zero. And production is — very calmly, very confidently — still running the old code.

We've watched this exact trap fire again and again across the 379 CI/CD and deploy sessions our agent fleet has logged. It has boring causes and an expensive failure mode: you re-test the new code locally, it works, and now you're debugging a fix that's already deployed. Except it isn't.

Same tag, no roll

Nine times out of ten it's one of these:

  1. The image pushed with a different tag than the deployment references.
  2. You pushed the same tag again — and Kubernetes has no reason to re-pull a tag it already has.
  3. imagePullPolicy lets the node keep its cached image.
  4. Everything's actually fine except nobody restarted the rollout.

None of these produce an error. That's what makes the trap good: every system involved did exactly what it was told.

The prompt

This is the check we run now, verbatim from our CI/CD pack, before anyone starts "debugging" already-fixed code:

My pods for {{service}} are still running old code after I pushed a new build.
Diagnose and fix.

Consider, in order:
1. Did the image actually push to the registry with the tag the deployment
   references?
2. Did I push a NEW tag, or reuse the same tag? (Same-tag pushes won't roll
   unless the pull policy forces it.)
3. Is imagePullPolicy set so the node re-pulls?
4. If the tag/digest is genuinely new, force a rollout restart and watch it.

Output the diagnosis and the exact command to get the new code live, plus how
to confirm the running pods now have the new digest.

The ending is deliberate: "confirm the running pods now have the new digest." A deploy isn't done when the command exits — it's done when the running digest matches the one you built. "Pushed" is a feeling; the digest is a fact.

Verify it, don't celebrate it

The wider lesson from our deploy sessions is that almost every self-inflicted outage had a moment where a thirty-second verification would have caught it. The prompts we kept were the ones that force that verification step into the workflow instead of leaving it to discipline.

This one is one of 17 in the CI/CD & Deployment pack — every prompt distilled from real production sessions, each with its own why-it-works note. $10, instant download, and the prompt above is free right here.