---
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
---

# 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 and setup{% #requirements-and-setup %}

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 later), an [APM-instrumented application](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries.md), and [Remote Configuration](https://docs.datadoghq.com/tracing/guide/remote_config.md).

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

Manage Live Debugger for each service and environment from the Live Debugger Settings page. Each service can be in one of three modes:

- Automatic: Eligible services are enabled automatically. Switch a service to Enabled for a faster debugging experience with debug symbols.
- Enabled: Live Debugger is ready to use on this service in this environment, with faster setup and a better debugging experience.
- Disabled: This service is explicitly disabled and is not enabled automatically.

### Minimum tracer versions{% #minimum-tracer-versions %}

Live Debugger requires the following minimum tracer versions:

- [Python](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/python.md) ≥ 4.11.0
- [Java](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/java.md) ≥ 1.64.0
- [.NET](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/dotnet-core.md) ≥ 3.46.0
- [Ruby](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/ruby.md) ≥ 2.35.0
- [Node.js](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/nodejs.md) ≥ 5.109.0
- [PHP](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/php.md) ≥ 1.21.0
- [Go](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/go.md) ≥ 2.9.0

Older tracer versions might require enabling Live Debugger through an environment variable. Follow the setup instructions for your language:

{% alert level="info" %}
Why DI instructions? Live Debugger is built on [Dynamic Instrumentation (DI)](https://docs.datadoghq.com/tracing/dynamic_instrumentation.md), so its setup instructions and limitations also apply here.
{% /alert %}

### 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).

### Create a logs index{% #create-a-logs-index %}

Live Debugger generates logs that are sent to Datadog and appear alongside your application logs.

If you use [Exclusion filters](https://docs.datadoghq.com/logs/log_configuration/indexes.md#exclusion-filters), make sure Live Debugger logs are not filtered:

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 Dynamic Instrumentation 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.

### Link your source code{% #link-your-source-code %}

If you enable the Datadog Source Code Integration, you can debug code directly through Live Debugger.

## 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:
   - On the [Live Debugger page](https://app.datadoghq.com/debugging/sessions), click Create Debug Session.
   - (Requires the [Code Origin](https://docs.datadoghq.com/tracing/code_origin.md) feature) In the [Trace Explorer](https://app.datadoghq.com/apm/traces), open a trace, locate the Code Origin section in the side panel, and click Start Debug Session.
1. Add a logpoint to begin collecting diagnostic data.
1. Add, remove, or modify logpoints as needed during the session.

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/sessions).
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) Enable "Capture Variables" to collect all execution context (this feature is rate-limited to 1 execution per second).
1. (Optional) Define a condition for when the logs should be emitted.

**Note:** Some feature limitations may apply depending on the service's runtime language. Review the [runtime language-specific documentation](https://docs.datadoghq.com/dynamic_instrumentation/enabling.md) for more details.

### 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.
- 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. Each tracer includes additional language-specific redaction rules.

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 %}

[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.

## Impact on performance and billing{% #impact-on-performance-and-billing %}

Enabling Live Debugger on a service does not trigger data capture or impact performance. Data capture only occurs when there are active Debug Sessions on that service.

**Performance impact**: Datadog's agent-driven instrumentation ensures minimal impact on application performance; sampling logic, rate limits, and built-in budgets prevent runaway data capture.

**Pricing impact**: Logs captured by Datadog are all billed the same way. This applies whether they are generated from Live Debugger or logger lines in your source code. With Live Debugger, the logpoints automatically expire after the set time period, limiting unnecessary data accumulation and costs. Monitor your [Datadog Plan & Usage page](https://app.datadoghq.com/account/billing) for any unexpected increases after utilizing a new feature.

## 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 %}

- [Troubleshoot faster with the GitLab Source Code integration in Datadog](https://www.datadoghq.com/blog/gitlab-source-code-integration)
- [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)