# Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler

DevFeed: [Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler](<https://devfeed.tech/articles/kubernetes-v1-37-scale-workloads-to-zero-with-horizontalpodautoscaler-4577.md>)

Original publisher: [Read original article](<https://kubernetes.io/blog/2026/09/02/kubernetes-v1-37-hpa-scale-to-zero-beta/>)

Author: Johannes Würbach

Published: 2026-09-02T18:30:00Z

Content type: release

Language: en

Sources: [Kubernetes Blog](<https://devfeed.tech/sources/kubernetes-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [autoscaling](<https://devfeed.tech/topics/autoscaling.md>)

Tags: [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [prometheus](<https://devfeed.tech/tags/prometheus.md>)

## AI overview

Kubernetes v1.37 adds beta, default-enabled HPA support for scaling eligible workloads to zero and back using object or external metrics. It explains queue-based scaling, cold-start trade-offs, and the metrics adapter setup required for an external Prometheus metric.

## Source excerpt

Kubernetes v1.37 includes API support for horizontal autoscaling of workloads down to zero replicas. This feature is now Beta and enabled by default. A HorizontalPodAutoscaler (HPA) that uses a suitable object metric or external metric can now scale a workload to zero replicas, then bring it back when the metric changes. Before v1.37, you needed an add-on or external component, or you had to enable the Alpha feature gate, to scale from zero. It is now part of core Kubernetes. Scaling to zero removes the last idle Pod from workloads such as queue consumers and batch processors. The savings are largest when each Pod reserves expensive resources, including dedicated CPUs or GPUs. The trade-off is cold-start time: the HPA must observe the metric, schedule a Pod, and start the application. This works well when work can wait in a durable queue. Kubernetes Services do not buffer requests while no Pods are ready, so HTTP and other request-driven workloads need a separate buffering layer. Why scaling from zero needs a different metric The HPA commonly scales on CPU or memory usage. Both metrics come from running Pods. Once the replica count reaches zero, there are no Pods left to measure and no signal that can tell the HPA to scale back up. Object and external metrics do not have that limitation. A queue length, for example, exists independently of the workers that consume it. The HPA can continue reading the queue length while no workers are running. The following example scales a queue consumer to and from zero using an external metric. Configure an external metric The following example uses a Prometheus metric named queue_consumer_lag. It assumes that Prometheus already collects a series similar to this one: queue_consumer_lag{namespace="default",name="worker_tasks"} Kubernetes needs a metrics adapter to make that value available through the External Metrics API. One implementation is the Prometheus Adapter, which can expose the series using an externalRules entry: extern