Bits Remediation

Recommends infrastructure remediation from within a Bits investigation and, for supported Kubernetes actions currently in Preview, executes the recommended action against the customer cluster when an authorised user clicks Run.

Recorded characteristics

Function

After Bits Investigation identifies a root cause, Bits can recommend a remediation action for infrastructure-related issues, such as scaling a deployment, restarting a pod or patching a resource. Datadog documents two distinct paths. With manual recommendations, Bits produces a suggested command (for example a kubectl patch command) that the user copies and runs in their own CLI, so Bits itself changes nothing. With one-click actions, currently in Preview for Kubernetes, the user clicks Run and Bits executes the suggested remediation action directly from the investigation context. Bits can subsequently verify whether the remediation action was applied successfully and whether the original issue was resolved, through a Verify Resolution control. This record covers infrastructure remediation only; the code-fix and triage-action features described on the same Datadog page (pull requests through Bits Code, Slack/Teams messages, incidents, paging, work items and Jira tickets) are outside this boundary.

Data access

Datadog documents remediation as operating on the context of the Bits investigation in which the recommendation appears, including the identified root cause and the affected infrastructure resource, and on the Kubernetes action definitions in the Action Catalog together with the Private Action Runner and Connection configuration that reach the target cluster. Guardrail evaluation uses the environment, service and resource tags of the targeted action. The result of the remediation action and the status of the original issue are read back when Verify Resolution is used. Datadog does not itemise any further data set for the remediation feature specifically, so the wider Bits Investigation telemetry model is not recorded here as remediation data access.

Actions

Can take actions

External actions

Yes

Human confirmation

Required

Permission basis

Mixed

Administrative control

Bits Guardrails (Preview) let admins define which remediation actions Bits can take, where those actions apply and who needs to approve them. A guardrail is configured by choosing the actions to target (one or more available actions for an integration such as Kubernetes), defining the guardrail scope (environment, service and resource tags), and setting the enforcement level. Datadog currently documents two enforcement levels: Ask, which requires user approval before Bits executes actions and lets admins choose which teams, roles or individuals can approve; and Deny, under which Bits can recommend an action but cannot take it. No enforcement level permitting unattended execution is documented. Guardrails require the Guardrails Read and Guardrails Write permissions, enabled in Organizational Settings > Roles. Beyond guardrails, execution depends on organisation-level controls: joining the Preview programme via Request Access, deploying a Private Action Runner with network access to the cluster, pairing it with a Connection to the Kubernetes integration, restricting who may use that connection, and granting a user role with permission to run actions and resolve the Kubernetes connection. Which actions are available at all is governed by the Action Catalog, and for ownerless Agent runners by Execution Policies, which can allow or deny specific actions and apply scopes such as target Kubernetes namespaces. Datadog does not document a remediation-specific audit or execution history view on these pages.

Default state

Disabled

Availability

Bits Remediation is documented as including capabilities in Preview, with Request Access required to join the Preview programme. Kubernetes one-click actions are explicitly in Preview, and Bits Guardrails are explicitly in Preview. Manual command recommendations are presented without a Preview label and so appear more broadly available than one-click execution. The documentation page is marked as not supported for every Datadog site, so site availability varies. Prerequisites for executable Kubernetes remediation are a Private Action Runner with network access to the cluster, a Connection to the Kubernetes integration, Action Catalog support for the action, and a user role with permission to run actions and resolve the connection. Remediation is surfaced from a Bits Investigation.

Licensing

Datadog does not state a licence tier, plan or SKU requirement for Bits Remediation on the pages reviewed; access to the executable features is gated by Preview enrolment rather than by any documented plan.

External model or provider

Not established

Limitations and uncertainty

Manual command recommendations are not execution: Bits generates the command and the user runs it themselves, which alone would not amount to a state-changing capability. Only one-click actions represent execution by Bits, and those are Preview and currently limited to Kubernetes. Datadog names scaling a deployment, restarting a pod and patching a resource as examples and refers to the Action Catalog for the full supported list rather than enumerating the Bits-executable subset, so the precise scope of one-click actions is not established; no arbitrary infrastructure control should be inferred. Guardrails are Preview and only Ask and Deny enforcement levels are documented; whether any configuration permits unattended execution is not established, and human confirmation is recorded as required on the documented behaviour of clicking Run or approving under Ask. The runtime identity reaching the cluster is documented at platform level (Datadog authorises the requesting user before dispatch; the runner uses credentials stored locally and referenced by the Connection, or Agent-tag-based Execution Policies) but Datadog does not state which model applies to Bits one-click actions specifically, nor whether execution impersonates the initiating user. No model or provider is identified for Bits Remediation. Verify Resolution is documented only by observable outcome; how it re-reads infrastructure state or telemetry is not documented. Targets other than Kubernetes are not established for one-click execution. Datadog does not document a remediation audit log on these pages.

Evidence

• Bits Remediation

  Supports: Function · Data access · Actions · External actions · Human confirmation · Permission basis · Admin controls · Default state · Availability · External model · Limitations · Primary source

  For infrastructure-related issues, Bits can recommend a remediation action, such as scaling a deployment, restarting a pod, or patching a resource. Manual recommendations: copy the suggested command (for example a kubectl patch command) and run it in your own CLI. One-click actions (Preview): click Run to let Bits execute the suggested remediation action directly from the investigation context. Bits can verify whether the remediation action was applied successfully and whether the original issue was resolved; click Verify Resolution to validate the status of the remediation action and the issue.

  Remediation is offered after Bits helps identify a root cause from an investigation and is executed from the investigation context; guardrail scope is defined by the environment, service and resource tags the guardrail applies to.

  One-click actions let Bits execute the suggested remediation action rather than only suggesting a command. Documented remediation examples are scaling a deployment, restarting a pod and patching a resource. Kubernetes actions are supported in Preview, with the Action Catalog holding the full list of supported actions and how to enable them.

  Running one-click Kubernetes actions requires a Private Action Runner with network access to your Kubernetes cluster, paired with a Connection to the Kubernetes integration.

  One-click execution is initiated by the user clicking Run in the investigation context. Guardrail enforcement level Ask requires user approval before Bits executes actions, with admins choosing which teams, roles or individuals can approve; Deny allows Bits to recommend an action but not take it. No enforcement level permitting unattended execution is documented.

  Running one-click Kubernetes actions requires a user role with permission to run actions and resolve the Kubernetes connection.

  Bits Guardrails let admins define which remediation actions Bits can take, where those actions apply and who needs to approve them, via targeted actions, guardrail scope (environment, service, resource tags) and enforcement level. Guardrails require the Guardrails Read and Guardrails Write permissions, enabled in Organizational Settings > Roles.

  Executable remediation is gated: the Preview must be joined via Request Access, and one-click Kubernetes actions require a Private Action Runner, a Kubernetes connection and a user role permitted to run actions.

  Bits Remediation includes capabilities in Preview; one-click actions are in Preview and Bits Guardrails are in Preview, with Request Access required. The documentation notes the product is not supported for every selected Datadog site.

  Datadog does not identify any model or provider for Bits Remediation on the capability page.

  Manual recommendations require the user to copy and run the command themselves, so Bits does not perform the change on that path; only Kubernetes one-click actions are documented as executed by Bits, in Preview, with the full supported list deferred to the Action Catalog.

• Bits Investigation

  Supports: Function · Primary source

  Bits Investigation is an autonomous AI agent that investigates production issues, forms hypotheses, gathers telemetry and pinpoints root causes; remediation follows root-cause identification.

• Action Catalog

  Supports: Data access · Actions · Primary source

  The Action Catalog defines the actions, inputs, outputs and parameters that can be performed against infrastructure and integrations.

  Kubernetes actions in the Action Catalog include state-changing operations such as Restart deployment, Scale deployment horizontally, Scale deployment vertically, Patch deployment and Patch pod.

• Private Actions

  Supports: External actions · Primary source

  Private actions run against services in the customer private network, such as Kubernetes clusters; the runner runs in that network, receives action tasks from Datadog and runs each task against the target service, returning the result to Datadog.

• Authorize Private Actions

  Supports: External actions · Permission basis · Admin controls · Limitations · Primary source

  Datadog decides whether an action is allowed and the private action runner then runs it against the customer service.

  Before a task is sent to a runner, Datadog checks whether the requesting user is permitted to act on that runner; if not allowed the task is never dispatched. A connection references the credentials needed to run the action against the service, stored locally with the runner and paired with a single runner.

  Execution Policies can allow or deny specific actions or sets of actions and apply integration-specific scopes such as target Kubernetes namespaces.

  Datadog documents two authorisation models for runners (Execution Policies and Connections) without stating which applies to Bits one-click remediation.

• Connections

  Supports: Permission basis · Admin controls · Primary source

  Using a connection requires the appropriate permission for that connection, and access can be restricted so only intended users can use it.

  Connections can be restricted, grouped and granted with resolver permission so only intended users can use them.

• Datadog Role Permissions

  Supports: Permission basis · Primary source

  Datadog role permissions govern which users hold the permissions required to run actions and administer guardrails.

• Bits AI

  Supports: Availability · Primary source

  Bits Remediation is documented as part of the Bits AI product family.