---
title: Live Debugger
description: >-
  Debug running applications in real time using non-breaking logpoints that
  collect information without stopping execution or redeploying code.
breadcrumbs: Docs > APM > Live Debugger
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Live Debugger

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}).
{% /alert %}

{% /callout %}

## Overview{% #overview %}

Live Debugger lets you inspect application behavior in real time, directly in running services, without redeploying code or interrupting execution.

Instead of adding temporary debug logs or reproducing issues locally, you can dynamically capture application state at specific points in the code. This includes variable values, method parameters, and execution context. Live Debugger is well suited for diagnosing issues in production or other long-running environments.

Live Debugger uses logpoints: auto-expiring, non-breaking breakpoints that collect diagnostic data without pausing the application. Since execution continues normally, Live Debugger can be used safely on production systems to investigate problems as they happen.

## Key capabilities{% #key-capabilities %}

Live Debugger provides:

- **Real-time inspection** of variable values, method arguments, and execution context in running code.
- **Safe, non-invasive data capture** that collects debugging information without pausing applications or requiring redeploys.
- **Dynamic logpoint placement** anywhere in your codebase, including in third-party libraries.
- **Auto-expiring logpoints** that deactivate automatically after a configurable duration.
- **Conditional data capture** based on user-defined expressions, so information is collected only when specific conditions are met.
- **Built-in [sensitive data scrubbing](https://docs.datadoghq.com/dynamic_instrumentation/sensitive-data-scrubbing.md)** to help prevent exposure of personal data, secrets, and credentials.

## Requirements{% #requirements %}

Live Debugger supports Python, Java, .NET, Ruby, Node.js, PHP, and Go. It requires:

- The [Datadog Agent](https://docs.datadoghq.com/agent.md), version 7.49.0 or higher
- An installed [Datadog SDK](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries.md) (see the Enable Live Debugger section for minimum SDK versions)
- [Unified Service Tagging](https://docs.datadoghq.com/getting_started/tagging/unified_service_tagging.md) configured with `service`, `env`, and `version` tags on your deployment
- [Remote Configuration](https://docs.datadoghq.com/tracing/guide/remote_config.md) enabled in the Agent
- (Recommended) [Source Code Integration](https://docs.datadoghq.com/integrations/guide/source-code-integration.md)

### Permissions{% #permissions %}

The following permissions are required to use Live Debugger:

- **Live Debugger Read** (`live_debugger_read`): Required to access the Live Debugger page.
- **Live Debugger Write** (`live_debugger_write`): Required to create or modify Debug Sessions and logpoints.
- **Live Debugger Redaction Write** (`live_debugger_redaction_write`): Required to change the redaction mode for captured data.

For more information about roles and how to assign roles to users, see [Role Based Access Control](https://docs.datadoghq.com/account_management/rbac/permissions.md#apm).

## Setup{% #setup %}

### Enable Live Debugger{% #enable-live-debugger %}

Live Debugger enablement depends on your service's runtime language. See the following language-specific sections for enablement instructions and minimum SDK versions.

You can disable Live Debugger for a service and environment from the [Live Debugger Settings page](https://app.datadoghq.com/debugging/settings), regardless of runtime language or SDK version.

**Note**: Live Debugger can work on older SDK versions through manual enablement, but you may encounter missing capabilities, unexpected errors, or a degraded experience. Datadog recommends keeping your SDK up to date.

#### Enable for Java, Python, .NET, and Node.js{% #enable-for-java-python-net-and-nodejs %}

You can enable Live Debugger in-app in one of two ways:

- On the [Live Debugger Settings page](https://app.datadoghq.com/debugging/settings), enable the service and environment.
- Start a Debug Session. Live Debugger is enabled automatically on the selected service and environment.

Either option requires one of the following minimum SDK versions:

| Language | Minimum SDK version |
| -------- | ------------------- |
| Java     | 1.48.0              |
| Python   | 3.10.0              |
| .NET     | 3.29.0              |
| Node.js  | 5.84.0              |

If your SDK version is lower, or you prefer to configure Live Debugger with environment variables, use the following manual configuration steps.

{% tab title="Java" %}
**SDK version**: [Datadog Java SDK](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/java.md) version 1.64.0 or higher is strongly recommended, running on JDK 8 or higher. The minimum SDK version is 1.42.0, but it may result in unexpected errors and a degraded experience.

Start your service with `DD_DYNAMIC_INSTRUMENTATION_ENABLED=true`, along with `DD_SERVICE`, `DD_ENV`, and `DD_VERSION`. The `-javaagent` argument must come before `-jar`:

```shell
export DD_SERVICE=<YOUR_SERVICE>
export DD_ENV=<YOUR_ENV>
export DD_VERSION=<YOUR_VERSION>
export DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
java \
    -javaagent:dd-java-agent.jar \
    -jar <YOUR_SERVICE>.jar
```

**Note**: On JDK 18 and earlier, classes compiled with the `-parameters` flag (default in Spring 6+, Spring Boot 3+, and Scala) may fail to instrument with the error `Method Parameters detected`.
{% /tab %}

{% tab title="Python" %}
**SDK version**: [Datadog Python SDK (`ddtrace`)](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/python.md) version 4.11.0 or higher is strongly recommended. The minimum SDK version is 2.9.0, but it may result in unexpected errors and a degraded experience.

Install `ddtrace`, then start your service with `DD_DYNAMIC_INSTRUMENTATION_ENABLED=true` and `ddtrace-run`:

```shell
pip install ddtrace
export DD_SERVICE=<YOUR_SERVICE>
export DD_ENV=<YOUR_ENV>
export DD_VERSION=<YOUR_VERSION>
export DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
ddtrace-run python -m myapp.py
```

{% /tab %}

{% tab title=".NET" %}
**SDK version**: [Datadog .NET SDK](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/dotnet-core.md) version 3.46.0 or higher is strongly recommended. The minimum SDK version is 3.9.0, but it may result in unexpected errors and a degraded experience.

Start your service with the following environment variables set:

```shell
DD_SERVICE=<YOUR_SERVICE>
DD_ENV=<YOUR_ENV>
DD_VERSION=<YOUR_VERSION>
DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
```

{% /tab %}

{% tab title="Node.js" %}
**SDK version**: [Datadog Node.js SDK (`dd-trace-js`)](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/nodejs.md) version 5.109.0 or higher is strongly recommended. The minimum SDK version is 5.39.0, but it may result in unexpected errors and a degraded experience. If your source code is transpiled or bundled (for example, TypeScript, Babel, or Webpack), publish source maps with the deployed application so that logpoints map to the correct lines.

Start your service with the following environment variables set:

```shell
DD_SERVICE=<YOUR_SERVICE>
DD_ENV=<YOUR_ENV>
DD_VERSION=<YOUR_VERSION>
DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
```

{% /tab %}

#### Enable for Ruby, PHP, and Go{% #enable-for-ruby-php-and-go %}

Ruby and PHP require manual configuration through environment variables. Go requires an Agent-level configuration first, after which the service can be enabled in-app (Go SDK 2.6.0 or higher) or through environment variables.

{% tab title="Ruby" %}
**SDK version**: [Datadog Ruby SDK (`ddtrace`)](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/ruby.md) version 2.38.0 or higher is strongly recommended. The minimum SDK version is 2.37.0, but it may result in unexpected errors and a degraded experience.

**Additional requirements:**

- Ruby 2.6 or higher (MRI/CRuby only; JRuby is not supported)
- A Rack-based framework (Rails, Sinatra, or other Rack-compatible frameworks). Background workers (such as Sidekiq or Resque) are not supported.
- `RAILS_ENV` or `RACK_ENV` set to `production`

Start your service with the following environment variables set:

```shell
export DD_SERVICE=<YOUR_SERVICE>
export DD_ENV=<YOUR_ENV>
export DD_VERSION=<YOUR_VERSION>
export DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
```

**Note**: Live Debugger initializes on the first HTTP request. Your service must receive at least one request before you can create a logpoint.
{% /tab %}

{% tab title="PHP" %}
**SDK version**: [Datadog PHP SDK (`dd-trace-php`)](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/php.md) version 1.23.0 or higher is strongly recommended. The minimum SDK version is 1.5.0, but it may result in unexpected errors and a degraded experience.

Start your service with the following environment variables set:

```shell
DD_SERVICE=<YOUR_SERVICE>
DD_ENV=<YOUR_ENV>
DD_VERSION=<YOUR_VERSION>
DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
```

{% /tab %}

{% tab title="Go" %}
Go services require enabling Live Debugger in both the Datadog Agent and the application.

**SDK version**: [Datadog Go SDK](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/go.md) version 2.9.0 or higher is strongly recommended (or 1.74.6 or higher on the v1 line).

**Additional requirements:**

- [Datadog Agent](https://docs.datadoghq.com/agent.md) version 7.73.0 or higher, running on the same host as your application
- Linux kernel 5.17 or higher

**Configure the Datadog Agent** using one of the following methods, depending on how you deploy the Agent:

- **Configuration YAML file**: Update `system-probe.yaml` (located alongside `datadog.yaml`) with the following. For more information, see [Agent configuration files](https://docs.datadoghq.com/agent/configuration/agent-configuration-files.md?tab=agentv6v7#agent-main-configuration-file).

  ```yaml
  dynamic_instrumentation:
    enabled: true
  ```

- **Environment variable**: Add the following to your Datadog Agent manifest:

  ```
  DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
  ```

- **Helm**: Add the following to your Helm chart:

  ```yaml
  datadog:
    dynamicInstrumentationGo:
      enabled: true
  ```

**Configure your service**: After the Agent is configured, services on the same host can be enabled from the [Live Debugger Settings page](https://app.datadoghq.com/debugging/settings), or by starting the service with the following environment variables set:

```shell
DD_SERVICE=<YOUR_SERVICE>
DD_ENV=<YOUR_ENV>
DD_VERSION=<YOUR_VERSION>
DD_DYNAMIC_INSTRUMENTATION_ENABLED=true
```

{% /tab %}

#### Enablement modes{% #enablement-modes %}

On the [Live Debugger Settings page](https://app.datadoghq.com/debugging/settings), you can check and update the enablement status of each service and environment. Each service and environment can be in one of three modes:

- Automatic: Live Debugger has not been set to Enabled or Disabled yet on this service and environment. This setting changes to Enabled automatically the first time a Debug Session is started. For a faster first-time debugging experience, switch the setting to Enabled in advance.
- Enabled: Live Debugger is activated on the selected service and environment, including debug symbol uploads and faster delivery of new logpoints.
- Disabled: Logpoints cannot be created or reactivated on the given service and environment. It applies regardless of runtime language or SDK version.

### (Recommended) Create a logs index{% #create-a-logs-index %}

Live Debugger generates logs that are sent to Datadog and appear alongside your application logs. A dedicated logs index helps ensure these logs aren't unintentionally filtered out, especially if you use [Exclusion filters](https://docs.datadoghq.com/logs/log_configuration/indexes.md#exclusion-filters).

To create the index:

1. Create a logs index and [configure it](https://docs.datadoghq.com/logs/log_configuration/indexes.md#add-indexes) to the desired retention with **no sampling**.
1. Set the filter to match on the `source:dd_debugger` tag. All Live Debugger logs have this source.
1. Make sure the new index takes precedence over any other with filters that match that tag, because the first match wins.

### (Recommended) Link your source code{% #link-your-source-code %}

Set up [Source Code Integration](https://docs.datadoghq.com/integrations/guide/source-code-integration.md) to view source code files directly in Live Debugger. After you link the service and environment to the corresponding repository and Git commit SHA, you can add logpoints and see existing ones in the source code as you would with breakpoints in an IDE. This helps you confirm logpoints are placed accurately and avoid capturing unintended data or generating invalid results.

**Note**: Source Code Integration is optional when starting a Debug Session manually, but it is required when using [Bits Live Debugger](https://docs.datadoghq.com/tracing/live_debugger/bits-live-debugger.md).

## Using Live Debugger{% #using-live-debugger %}

### Creating and using a Debug Session{% #creating-and-using-a-debug-session %}

A Debug Session lets you inspect running code using auto-expiring logpoints. To create and use a Debug Session:

1. Start a Debug Session from one of the following locations:
   - (Preview) On the [Live Debugger page](https://app.datadoghq.com/debugging/), submit a question or investigation prompt to [Bits Live Debugger](https://docs.datadoghq.com/tracing/live_debugger/bits-live-debugger.md#start-a-debugging-session).
   - On the [Live Debugger page](https://app.datadoghq.com/debugging/), click Create Debug Session or New Session.
   - In the [Trace Explorer](https://app.datadoghq.com/apm/traces), open a trace, locate the [Code Origin](https://docs.datadoghq.com/tracing/code_origin.md) section in the side panel, and click Start Debug Session.
1. Select a code location to add the first logpoint and begin capturing log events.
1. Add, remove, or modify logpoints as needed during the session.
1. Log events captured by the logpoints appear in the Debug Session view as they are ingested and indexed. You can also view, query, and analyze these logs in Logs Explorer and other Datadog tools that reference log data.
1. View active and inactive Debug Sessions created by users in your organization in the Live Debugger Sessions list. A Debug Session's log events are visible only during the retention period defined for the logs index.

Debug Sessions expire automatically. You can also manually disable or re-enable a session, as well as individual logpoints, at any time.

### Creating logpoints{% #creating-logpoints %}

Logpoints are "non-breaking breakpoints" that specify where in the code to capture information, what data to include, and under what conditions. To add a logpoint for debugging:

1. Go to the [Live Debugger page](https://app.datadoghq.com/debugging/).
1. Click Create Debug Session.
1. Choose your service, environment, and select where in your code to place the first logpoint.
1. Define a logpoint message template using the [expression language](https://docs.datadoghq.com/dynamic_instrumentation/expression-language.md).
1. (Optional) Use the Capture Variables option to collect all execution context or specific variables as part of the log event metadata (this feature is rate-limited to 1 execution per second). To capture only a log message string, remove the capture variables option from the logpoint definition.
1. (Optional) Define a condition for when the logs should be emitted.
1. Click Apply changes to save modifications to existing logpoint definitions.

Most logpoint settings can be modified after creation, even if the logpoint already started capturing log events. However, the logpoint's originally selected service, environment, and code location cannot be modified (a new logpoint or Debug Session should be created in this case).

After a logpoint is created, modified, or re-activated, it can take a couple of minutes to instrument the code and begin capturing log events. **Note**: If the selected code is not executed or the logpoint condition(s) are not met, then no log events are generated.

### Protecting sensitive data{% #protecting-sensitive-data %}

Live Debugger data might contain sensitive information, especially when using the Capture Variables option. Live Debugger automatically applies mode-based and identifier-based redaction to help protect this data.

#### Mode-based redaction{% #mode-based-redaction %}

Live Debugger has two redaction modes:

- Strict Mode: Redacts all values except numbers and Booleans. [Bits Live Debugger](https://docs.datadoghq.com/tracing/live_debugger/bits-live-debugger.md) is not available for service and environment combinations set to Strict Mode.
- Targeted Mode: Redacts known sensitive patterns such as credit card numbers, API keys, IPs, and other PII. It also runs a high-entropy secrets scanner that automatically redacts likely secrets, which appear as `[REDACTED:HIGH_ENTROPY]` in captured data.

These redaction modes cannot be disabled, only switched. Targeted Mode is applied automatically in common pre-production environments such as `staging` or `preprod`. Changing the redaction mode requires the **Live Debugger Redaction Write** permission.

#### Identifier-based redaction{% #identifier-based-redaction %}

Variable values associated with common sensitive identifiers (for example, `password`, `accessToken`, and similar terms) are scrubbed before captured data leaves the host. Additional language-specific redaction rules are built into each SDK.

You can extend redaction behavior through:

- Custom identifier-based redaction
- Class/type-based redaction rules
- Sensitive Data Scanner rules

See the [sensitive data scrubbing](https://docs.datadoghq.com/dynamic_instrumentation/sensitive-data-scrubbing.md) instructions and [Sensitive Data Scanner](https://docs.datadoghq.com/dynamic_instrumentation/sensitive-data-scrubbing.md#redact-based-on-variable-values-with-sensitive-data-scanner) documentation for configuration details.

### Bits Live Debugger{% #bits-live-debugger %}

{% alert level="info" %}
Bits Live Debugger is in Preview. [Learn more about Bits Live Debugger and request access](https://docs.datadoghq.com/tracing/live_debugger/bits-live-debugger.md).
{% /alert %}

[Bits Live Debugger](https://docs.datadoghq.com/tracing/live_debugger/bits-live-debugger.md) lets you investigate a running service by describing the issue in plain language. Bits Code handles logpoint placement, captures variable snapshots, and helps interpret the results.

**Note**: [Bits Live Debugger](https://docs.datadoghq.com/tracing/live_debugger/bits-live-debugger.md) requires the service and environment to be in Targeted Mode. See Mode-based redaction for details.

## Limitations{% #limitations %}

The following constraints apply to Live Debugger usage and configuration:

- **Configuration scope:** Live Debugger and Dynamic Instrumentation are enabled or disabled together for the same service and environment.
- **Rate limits:**
  - Logpoints with variable capture: Limited to 1 execution per second.
  - Logpoints without variable capture: Limited to 5000 executions per second, per service instance.

## Further Reading{% #further-reading %}

Additional helpful documentation, links, and articles:

- [Dynamic Instrumentation](https://docs.datadoghq.com/dynamic_instrumentation.md)
- [Dynamic Instrumentation Expression Language](https://docs.datadoghq.com/dynamic_instrumentation/expression-language.md)
- [Sensitive Data Scrubbing](https://docs.datadoghq.com/dynamic_instrumentation/sensitive-data-scrubbing.md)
- [Autocomplete and Search](https://docs.datadoghq.com/dynamic_instrumentation/symdb.md)
- [Exception Replay](https://docs.datadoghq.com/error_tracking/backend/exception_replay.md)
- [Identify and fix code issues faster with Datadog's Azure DevOps Source Code integration](https://www.datadoghq.com/blog/azure-devops-source-code-integration/)
- [Troubleshoot faster with the GitLab Source Code integration in Datadog](https://www.datadoghq.com/blog/gitlab-source-code-integration)