← Problem Library
K8s L4 K8S 1364 · 12 min

A ServiceMonitor exists and Prometheus scrapes nothing because the monitor moved namespaces while the operator still watches only its original tenant set

The object is valid, yet target discovery never sees it because the operator's namespace selector never followed the move.

K8sPlatform ReliabilityLevel 4Pro12 min
Scenario

A monitoring manifest cleanup centralizes resources and later one application's metrics vanish despite healthy endpoints.

What to check first
  • Identify the primary failure signal in the The Monitor Was Correct in a Namespace Prometheus Did Not Watch scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Verify operator namespace watch scope before rewriting labels or port names.

Questions worth viewing together
What should you verify first when A ServiceMonitor exists and Prometheus scrapes nothing appears?

Community-field Kubernetes problem inspired by Prometheus Operator patterns where a ServiceMonitor moved outside the operator watch scope. A valid monitor can still be invisible if it lives outside the operator's watch boundary.

What usually causes A ServiceMonitor exists and Prometheus scrapes nothing in production?

Teams often blame broken endpoints when discovery never included the monitor at all.

What should you document after resolving A ServiceMonitor exists and Prometheus scrapes nothing?

Namespace refactors for monitoring resources should always be checked against operator selectors.