Datadog Kubernetes Autoscaling

Name: Datadog Kubernetes Autoscaling
Brand: Datadog
Rating: 4.4 (2770 reviews)

Leader

Datadog provides cloud-scale monitoring and security for metrics, traces and logs in one unified platform.

Est 2010|Valuation $91.4B|Raised $795.9M

LinkedIn 546K|Website|Web traffic 4.6M|FTEs 8,100|HQ New York, New York, US

MarketsContainer Management Cloud Cost Management

Datadog Kubernetes Autoscaling screenshot

Published May 16, 2026

01Common complaints

1. If Datadog billing models are already causing material cost issues and the organization cannot tolerate increases in observed telemetry volume, adding autoscaling-managed changes may not address the underlying billing model concerns. 2. If the primary need is event-driven autoscaling based on external queues or streams and portability is a priority, a Kubernetes-native solution such as KEDA may be more appropriate. 3. If the primary objective is automated node-level optimization and bin packing, a specialist product focused on node automation (for example CAST AI) may provide more targeted functionality. 4. If Federal or FedRAMP/Government cloud availability is required for the autoscaling feature, the feature is not available on Datadog for Government (US1-FED) in the materials reviewed. 5. If an organization enforces GitOps-only change management and does not permit UI- or remote-config-driven modifications, it should validate whether DPA CRD-based GitOps workflows fully meet governance needs.

Deal disqualifiers (poor fit)

Small clusters where potential savings do not offset added platform complexity.
Strict requirements for open-source-only, air-gapped, or government-cloud-only deployments (the autoscaling feature is not available in some restricted government or air-gapped deployments).
Organizations that prohibit vendor-managed automation and require GitOps-only change management without UI-driven changes; teams should validate GitOps workflows using DPA CRDs.

Documented limitations

Not available on Datadog for Government (US1-FED).
Per-cluster limit: maximum documented number of workloads (for example, a 1000-workload cap for optimization) applies in the documentation reviewed.
Requires Remote Configuration to be enabled at the organization level and on agents.
Minimum agent and cluster agent versions are required for varying capabilities (recommendations, live scaling, GitOps workflows).

Roadmap / preview states

Some cluster autoscaling and node recommendation capabilities were described as limited-preview in vendor blog content.

Practical limitations reported by practitioners

Elastic infrastructure can increase monitoring costs, which is an operational and budgeting consideration rather than a product defect.
Alert and monitor tuning is required to avoid noise related to expected scaling events.

02Why they buy

Documented or claimed advantages

Integration of rightsizing recommendations with existing Datadog telemetry collected by agents.
Ability to apply changes from the Datadog platform via UI or by deploying DPA CRDs, enabling both centralized and GitOps-based workflows.
Preview and governance features to review recommendations and apply constraints before making live changes.
Cost-estimate context that can be used alongside Cloud Cost Management for more precise cost attribution.

Areas where competitors may have clearer advantages

Some competitors publish more transparent or unit-based pricing for optimization services.
Specialist platforms may provide deeper node-level automation (bin packing, spot instance strategies) and more aggressive cluster-level optimization.
Native Kubernetes tools and open-source solutions can reduce vendor dependence and are often preferred when portability is a high priority.

03Field reports

Review-platform context

Major review platforms (G2, TrustRadius, Gartner Peer Insights) generally present reviews for Datadog as a whole rather than the autoscaling feature in isolation. Therefore, customer commentary is directional and reflects how buyers experience Datadog in Kubernetes environments, including billing and operational aspects related to autoscaling.

Observations from review platforms

Dedicated autoscaling reviews for Datadog were not identified in the accessible results. Reviews for Datadog overall highlight broad integrations and an integrated platform approach, but these comments are not necessarily specific to the autoscaling feature.

Community feedback (sample themes)

- Cost sensitivity: community posts frequently discuss concerns about per-host billing and the visibility of costs as infrastructure scales. - Operational concerns during scaling events: practitioners report the need to tune alerting to avoid false positives during pod/node lifecycle events. - Ephemeral infrastructure visibility: comments note that data associated with terminated pods or nodes can disappear from entity-level views, complicating post-incident analysis unless teams rely on aggregated metrics, logs, or traces and consistent tagging strategies. Representative community quotes (paraphrased for context): - A practitioner reported that per-host billing combined with autoscaling created internal discussions about monitoring costs. - Users have asked how to avoid false-positive alerts during frequent scale-up/scale-down events, indicating that alert configuration needs to account for elasticity.

Why organizations adopt Datadog (observed themes)

Integrated platform across infrastructure monitoring, APM, and logs
Faster adoption paths for organizations already running Datadog Agents
Wide set of integrations for cloud providers and Kubernetes

Why some organizations discontinue Datadog (observed themes)

Cost unpredictability at scale (particularly with host- and ingestion-based billing)
Preference for cloud-native, open-source stacks to reduce vendor concentration
Cost-driven migration to DIY telemetry stacks when budget constraints are strong

Vendor announcements and claims (limited independent verification)

Vendor announcements describe continuous monitoring and automated rightsizing capabilities and reference internal analyses about container cost attribution (for example, vendor-published statistics regarding idle resource cost). These claims are vendor-published and the underlying methodology for specific statistics is not included in the announcements.

Practitioner write-up (independent blog)

Independent practitioner material describes how rightsizing recommendations can be used with Datadog tooling to identify over-allocation and balance cost and performance. These write-ups provide qualitative operational guidance but are not controlled ROI studies.

Availability of public, quantified case studies

Public, independently audited case studies that provide transparent before/after cost and SLO outcomes specifically for Datadog Kubernetes Autoscaling were limited in the materials reviewed.

04Best fit

Company size

Most likely fit:

Mid-market to enterprise organizations where Kubernetes usage is large enough that rightsizing materially affects budgets.
Organizations already licensed for the Datadog platform where additional rightsizing capabilities would leverage existing telemetry.

Industries

Common adopters include SaaS, fintech, e-commerce, marketplaces, and media/streaming — generally organizations with microservices architectures and elastic workloads.

Roles / personas

Decision makers: Head of Platform Engineering, SRE leadership, DevOps leadership, FinOps.
Operators: Platform engineers, SREs, and service owners who tune resources.

Pain points addressed

Overprovisioned CPU and memory requests resulting in cost waste.
Lack of confidence in modifying resource requests/limits without causing regressions.
Manual effort associated with maintaining HPA/VPA policies across many teams.

Qualification criteria (good fit)

Already running Datadog Agent and Datadog Cluster Agent and comfortable with Datadog governance.
Interest in workflows that link utilization signals to cost impact with controlled rollout mechanisms.
A mature tagging and ownership model to route recommendations to the appropriate teams.

05The pitch

What the product does (objective)

Datadog Kubernetes Autoscaling (often abbreviated internally as "DKA") is a Kubernetes resource optimization and autoscaling capability inside the Datadog platform that: - Produces rightsizing recommendations for Kubernetes workloads (CPU/memory requests/limits) using real-time and historical utilization and event signals. - Can optionally apply autoscaling changes via Datadog, either from the UI (remote configuration) or via a Kubernetes CRD called `DatadogPodAutoscaler` (DPA). - Extends beyond classic Kubernetes autoscaling patterns by supporting multidimensional scaling (not only replica count) and providing recommendations that include cost and savings estimates (especially when integrated with Datadog Cloud Cost Management). Vendor materials describe the feature as intended to reduce container resource waste while maintaining performance and operational constraints via policy controls, preview modes, and governance features. Vendor claims should be treated as directional; independent validation varies by organization. Primary official documentation: Datadog "Kubernetes Autoscaling" documentation, which includes prerequisites, documented limits (for example, a workload cap), and DPA usage instructions.

Target market and positioning

Most suitable customers include: - Existing Datadog customers running Kubernetes at meaningful scale, particularly those already using Datadog Container Monitoring / Infrastructure Monitoring and, optionally, Cloud Cost Management. - Platform engineering, SRE, and DevOps teams focused on cost control and operational safety when rightsizing workloads. Positioning relative to native Kubernetes tools: - Datadog documents DKA as an alternative to HPA/VPA for a workload when enabled and notes that enabling the feature typically involves removing existing HPA/VPA configurations for the target workload; a preview mode is available for assessment prior to full migration.

Get a comprehensive analysis of Datadog Kubernetes Autoscaling including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published May 16, 2026

01Common complaints

If Datadog billing models are already causing material cost issues and the organization cannot tolerate increases in observed telemetry volume, adding autoscaling-managed changes may not address the underlying billing model concerns.
If the primary need is event-driven autoscaling based on external queues or streams and portability is a priority, a Kubernetes-native solution such as KEDA may be more appropriate.
If the primary objective is automated node-level optimization and bin packing, a specialist product focused on node automation (for example CAST AI) may provide more targeted functionality.
If Federal or FedRAMP/Government cloud availability is required for the autoscaling feature, the feature is not available on Datadog for Government (US1-FED) in the materials reviewed.
If an organization enforces GitOps-only change management and does not permit UI- or remote-config-driven modifications, it should validate whether DPA CRD-based GitOps workflows fully meet governance needs.

Deal disqualifiers (poor fit)

Small clusters where potential savings do not offset added platform complexity.
Strict requirements for open-source-only, air-gapped, or government-cloud-only deployments (the autoscaling feature is not available in some restricted government or air-gapped deployments).
Organizations that prohibit vendor-managed automation and require GitOps-only change management without UI-driven changes; teams should validate GitOps workflows using DPA CRDs.

Documented limitations

Not available on Datadog for Government (US1-FED).
Per-cluster limit: maximum documented number of workloads (for example, a 1000-workload cap for optimization) applies in the documentation reviewed.
Requires Remote Configuration to be enabled at the organization level and on agents.
Minimum agent and cluster agent versions are required for varying capabilities (recommendations, live scaling, GitOps workflows).

Roadmap / preview states

Some cluster autoscaling and node recommendation capabilities were described as limited-preview in vendor blog content.

Practical limitations reported by practitioners

Elastic infrastructure can increase monitoring costs, which is an operational and budgeting consideration rather than a product defect.
Alert and monitor tuning is required to avoid noise related to expected scaling events.

02Why they buy

Documented or claimed advantages

Integration of rightsizing recommendations with existing Datadog telemetry collected by agents.
Ability to apply changes from the Datadog platform via UI or by deploying DPA CRDs, enabling both centralized and GitOps-based workflows.
Preview and governance features to review recommendations and apply constraints before making live changes.
Cost-estimate context that can be used alongside Cloud Cost Management for more precise cost attribution.

Areas where competitors may have clearer advantages

Some competitors publish more transparent or unit-based pricing for optimization services.
Specialist platforms may provide deeper node-level automation (bin packing, spot instance strategies) and more aggressive cluster-level optimization.
Native Kubernetes tools and open-source solutions can reduce vendor dependence and are often preferred when portability is a high priority.

03Field reports

Review-platform context

Observations from review platforms

Dedicated autoscaling reviews for Datadog were not identified in the accessible results. Reviews for Datadog overall highlight broad integrations and an integrated platform approach, but these comments are not necessarily specific to the autoscaling feature.

Community feedback (sample themes)

Cost sensitivity: community posts frequently discuss concerns about per-host billing and the visibility of costs as infrastructure scales.
Operational concerns during scaling events: practitioners report the need to tune alerting to avoid false positives during pod/node lifecycle events.
Ephemeral infrastructure visibility: comments note that data associated with terminated pods or nodes can disappear from entity-level views, complicating post-incident analysis unless teams rely on aggregated metrics, logs, or traces and consistent tagging strategies.

Representative community quotes (paraphrased for context):

A practitioner reported that per-host billing combined with autoscaling created internal discussions about monitoring costs.
Users have asked how to avoid false-positive alerts during frequent scale-up/scale-down events, indicating that alert configuration needs to account for elasticity.

Why organizations adopt Datadog (observed themes)

Integrated platform across infrastructure monitoring, APM, and logs
Faster adoption paths for organizations already running Datadog Agents
Wide set of integrations for cloud providers and Kubernetes

Why some organizations discontinue Datadog (observed themes)

Cost unpredictability at scale (particularly with host- and ingestion-based billing)
Preference for cloud-native, open-source stacks to reduce vendor concentration
Cost-driven migration to DIY telemetry stacks when budget constraints are strong

Vendor announcements and claims (limited independent verification)

Practitioner write-up (independent blog)

Availability of public, quantified case studies

Public, independently audited case studies that provide transparent before/after cost and SLO outcomes specifically for Datadog Kubernetes Autoscaling were limited in the materials reviewed.

04Best fit

Company size

Most likely fit:

Mid-market to enterprise organizations where Kubernetes usage is large enough that rightsizing materially affects budgets.
Organizations already licensed for the Datadog platform where additional rightsizing capabilities would leverage existing telemetry.

Industries

Common adopters include SaaS, fintech, e-commerce, marketplaces, and media/streaming — generally organizations with microservices architectures and elastic workloads.

Roles / personas

Decision makers: Head of Platform Engineering, SRE leadership, DevOps leadership, FinOps.
Operators: Platform engineers, SREs, and service owners who tune resources.

Pain points addressed

Overprovisioned CPU and memory requests resulting in cost waste.
Lack of confidence in modifying resource requests/limits without causing regressions.
Manual effort associated with maintaining HPA/VPA policies across many teams.

Qualification criteria (good fit)

Already running Datadog Agent and Datadog Cluster Agent and comfortable with Datadog governance.
Interest in workflows that link utilization signals to cost impact with controlled rollout mechanisms.
A mature tagging and ownership model to route recommendations to the appropriate teams.

05The pitch

What the product does (objective)

Datadog Kubernetes Autoscaling (often abbreviated internally as "DKA") is a Kubernetes resource optimization and autoscaling capability inside the Datadog platform that:

Produces rightsizing recommendations for Kubernetes workloads (CPU/memory requests/limits) using real-time and historical utilization and event signals.
Can optionally apply autoscaling changes via Datadog, either from the UI (remote configuration) or via a Kubernetes CRD called DatadogPodAutoscaler (DPA).
Extends beyond classic Kubernetes autoscaling patterns by supporting multidimensional scaling (not only replica count) and providing recommendations that include cost and savings estimates (especially when integrated with Datadog Cloud Cost Management).

Vendor materials describe the feature as intended to reduce container resource waste while maintaining performance and operational constraints via policy controls, preview modes, and governance features. Vendor claims should be treated as directional; independent validation varies by organization.

Primary official documentation: Datadog "Kubernetes Autoscaling" documentation, which includes prerequisites, documented limits (for example, a workload cap), and DPA usage instructions.

Target market and positioning

Most suitable customers include:

Existing Datadog customers running Kubernetes at meaningful scale, particularly those already using Datadog Container Monitoring / Infrastructure Monitoring and, optionally, Cloud Cost Management.
Platform engineering, SRE, and DevOps teams focused on cost control and operational safety when rightsizing workloads.

Positioning relative to native Kubernetes tools:

Datadog documents DKA as an alternative to HPA/VPA for a workload when enabled and notes that enabling the feature typically involves removing existing HPA/VPA configurations for the target workload; a preview mode is available for assessment prior to full migration.

Get a comprehensive analysis of Datadog Kubernetes Autoscaling including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →