Introduction

Yes, but the answer depends on how much history you want. Kubernetes can show recent Horizontal Pod Autoscaler activity through the HPA object status and event stream, but it does not keep a long-lived built-in audit history of scaling decisions by default. For recent checks, kubectl describe hpa is usually enough. For durable history, you need external monitoring, event export, or control-plane logs.

Start With kubectl describe hpa

The quickest check is:

kubectl describe hpa <hpa-name>

This shows useful live information such as:

• current and desired replica counts
• target metrics and current metrics
• conditions
• recent events such as successful rescaling

If a recent scale-up or scale-down occurred, the Events section often tells you when and why.

Check the Event Stream Directly

You can also inspect recent events in the namespace.

kubectl get events --sort-by=.lastTimestamp

Or filter for autoscaler-related events:

kubectl get events --sort-by=.lastTimestamp | grep -i hpa

This is useful when you want a timeline view across several controllers rather than only one HPA object.

The catch is that Kubernetes events are not durable long-term history by themselves. They are meant for recent cluster diagnostics.

Read the HPA Status Fields

The HPA resource itself carries useful status information.

kubectl get hpa <hpa-name> -o yaml

Look at fields such as current metrics, desired replica counts, and conditions. This tells you the HPA's present state and some recent reasoning, even if it does not give you a permanent historical log of every scaling transition.

For Long-Term History, Use Monitoring

If the real question is "when did the HPA scale last week" or "how often does this workload rescale," you need durable observability outside the default object view.

Typical options are:

• Prometheus metrics and Grafana dashboards
• event exporters that persist Kubernetes events
• control-plane logs from the controller manager
• cloud-provider monitoring integrations

That is the operationally correct answer once you move beyond recent troubleshooting.

What Kubernetes Gives You by Default

By default, Kubernetes is good at showing:

• current HPA state
• recent events
• current metrics and desired replicas

It is not, by itself, a long-term HPA audit database.

That distinction matters because many people expect kubectl alone to answer historical autoscaling questions for arbitrarily old events.

A Practical Workflow

For day-to-day debugging, this is a sensible sequence:

kubectl describe hpa my-app
kubectl get hpa my-app -o yaml
kubectl get events --sort-by=.lastTimestamp

If that is not enough, add durable monitoring rather than searching for a hidden built-in history command.

Common Pitfalls

The most common mistake is expecting Kubernetes events to be a permanent history store. They are useful for recent diagnostics, not for durable long-term audit retention.

Another issue is checking the HPA object without also checking events, which often contain the most human-readable explanation of a recent rescale.

Developers also sometimes look only at replica counts and miss the metrics and conditions that explain why the HPA acted.

Finally, if HPA history matters operationally, do not rely only on ad hoc kubectl inspection. Persist the relevant data through monitoring or log export.

Summary

• Use kubectl describe hpa <name> for the fastest recent view of HPA activity.
• Use kubectl get events --sort-by=.lastTimestamp for recent cluster event history.
• Inspect the HPA YAML to see current status and conditions.
• Kubernetes does not provide a durable built-in long-term HPA history by default.
• Use monitoring, event export, or control-plane logs when you need historical autoscaling analysis.