← Problem Library
K8s L4 K8S 1383 · 12 min

A Prometheus adapter exposes an external metric and the HPA never scales

The metric is present in Prometheus, yet the adapter cannot map it to the workload because one ownership label vanished.

K8sPlatform ReliabilityLevel 4Pro12 min
Scenario

An external-metric autoscaling path is introduced and later the HPA shows no data despite successful Prometheus queries.

What to check first
  • Identify the primary failure signal in the The Metric Existed and the Label the Adapter Needed Was Missing 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

Trace labels end to end through relabeling and adapter mapping before rewriting HPA specs.

Questions worth viewing together
What should you verify first when A Prometheus adapter exposes an external metric and the HPA never scales appears?

Community-field Kubernetes problem inspired by Prometheus adapter discussions where relabeling dropped the namespace label the HPA mapping depended on. Autoscaling adapters fail quietly when a single ownership label disappears between scrape and query.

What usually causes A Prometheus adapter exposes an external metric and the HPA never scales in production?

Teams often blame HPA API registration when the adapter cannot map the metric due to relabel loss.

What should you document after resolving A Prometheus adapter exposes an external metric and the HPA never scales?

Metric relabel changes should be regression-tested against any autoscaling adapters that depend on those labels.