A deployment copied a probe path from an older chart revision where an init step created the endpoint first.
Readiness remains false forever because the probe path is served only after a migration job that never actually runs in this revision
The container is fine, yet it never turns ready because the route the probe expects belongs to a startup step or job path missing from the deployed revision.
Scenario
What to check first
- Identify the primary failure signal in the Probe Route Assumption scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Validate the readiness contract of the current revision, not a previous migration path.
Questions worth viewing together
Community-field Kubernetes readiness problem inspired by Stack Overflow discussions where probes targeted routes only older startup flows created. A valid probe path in an older release may not exist in the current startup sequence.
Teams often keep tweaking failureThreshold when the endpoint is never created at all.
Probe paths can drift subtly across chart or bootstrap revisions.
Similar cases seen in the field