Scenario
A chart refactor preserves the service port number and later the monitoring stack intermittently loses scrape targets after rollout.
A Prometheus scrape target keeps flapping (servicemonitor-still-targeted-old-port-name)
Endpoints exist, yet discovery becomes unstable because the monitor references a port name that no longer resolves after chart cleanup.
What to check first
- Identify the primary failure signal in the The Port Number Stayed, the Port Name Contract Did Not 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
Check named port references in the ServiceMonitor before changing selectors or scraping intervals.
Questions worth viewing together
Community-field Kubernetes problem inspired by Prometheus community threads where a ServiceMonitor still referenced an old named port after a chart clea... Monitoring often binds to names, not just numbers, and chart cleanups can quietly break that contract.
Teams often blame target instability when the monitor is still looking for a retired port name.
Helm refactors should diff named ports against all dependent monitoring objects, not just workload manifests.
Similar cases seen in the field