A monitoring cleanup centralizes manifests and later one application's metrics vanish despite healthy endpoints.
A ServiceMonitor exists and Prometheus scrapes nothing because the monitor moved namespaces while the operator still watches only its original tenant scope
The object is valid, yet discovery never includes it because the operator's watch selector did not follow the namespace move.
Scenario
What to check first
- Identify the primary failure signal in the The Monitor Was Valid in a Namespace the Operator Never Watched 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 operator namespace watch scope before editing labels or service ports.
Questions worth viewing together
Community-field Kubernetes problem inspired by Prometheus Operator patterns where a ServiceMonitor moved outside the operator's watch scope. A correct monitor can still be invisible if it lives outside the operator's discovery boundary.
Teams often blame endpoint health when discovery never saw the monitor at all.
Namespace refactors for monitor objects should be validated against operator watch selectors.
Similar cases seen in the field