Overview

Exception Replay captures execution context and local variable values when an exception occurs, helping you diagnose, reproduce, and resolve issues faster. It records the surrounding state, including the stack trace and variable snapshots, then surfaces this data directly in Error Tracking alongside the rest of the issue details.

Exception Replay is designed for production use. Snapshots are rate-limited, and sensitive data is automatically redacted. When enabled, it waits for exceptions in an application and captures snapshots of the stack trace and local variables before forwarding them to Datadog.

Requirements & Setup

Exception Replay supports Python, Java, .NET, and PHP, and captures only APM-based exceptions. It requires the Datadog Agent and an APM-instrumented application. You can enable it for an entire environment, an individual service in-app, or a specific service using environment variables.

The enablement method depends on your tracer version and whether Remote Configuration is available. See the table below for details.

To enable Exception Replay in-app, navigate to the Exception Replay Settings page in Error Tracking, select the desired environment or service, and toggle it to Enabled.

If in-app enablement isn’t available, set the environment variable:

DD_EXCEPTION_REPLAY_ENABLED=true

This can also be used to override in-app configuration and takes precedence when both are set.

Create a logs index for Exception Replay snapshots

Create a logs index dedicated to Exception Replay snapshots and configure it with the desired retention and no sampling.

• Set the filter to match source:dd_debugger.
• Ensure the index takes precedence over other indexes matching this tag (the first match wins).

Link your source code

If you enable the Datadog Source Code Integration, you can see code previews directly inside your Error Tracking stack traces. When Exception Replay snapshots are captured, you can hover over variable names in the code preview to view their captured values.

Sensitive data redaction

Exception Replay applies automatic mode- and identifier-based redaction to ensure sensitive data is protected before snapshots become available.

Mode-based redaction

Exception Replay 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 snapshots.

These redaction modes cannot be disabled, only switched, and Targeted Mode is applied automatically in common pre-production environments like staging or preprod.

Identifier-based redaction

Variable values associated with common sensitive identifiers (for example, password, accessToken, and similar terms) are scrubbed before snapshots leave the host. Additional language-specific redaction rules are built into each tracer (for example, the Python tracer maintains a list of default sensitive identifiers).

You can extend redaction behavior through:

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

See the Dynamic Instrumentation Sensitive Data Scrubbing instructions and Sensitive Data Scanner documentation for configuration details.

Troubleshooting

Missing variable values

Exception Replay snapshots are rate-limited to one snapshot per exception type per instance per hour. In some runtimes, a snapshot is only captured after the second occurrence for a given exception.

Additional reasons a snapshot may not appear

• Exception Replay not enabled
• Snapshot occurred outside selected time window
• Third-party package exclusions (use DD_THIRD_PARTY_DETECTION_EXCLUDES to include these)
• Logs with source:dd_debugger missing due to Log Index retention settings or Exclusion Filters in preceding indexes
• Exception Replay is not available in the FedRAMP region
• Java: On JDK 18 and below, classes compiled with the -parameters flag may not be supported. Spring 6+, Spring Boot 3+, and Scala use this flag by default.

Use the query @error.debug_info_captured:true in Error Tracking Explorer to find errors with Exception Replay snapshots.

BatchUploader WARN messages on GovCloud (Java)

On GovCloud sites (app.ddog-gov.com), Java tracers may log periodic WARN messages from com.datadog.debugger.uploader.BatchUploader with HTTP 403 and text similar to This traffic is not permitted on your account. This is expected when debugger-related uploads are attempted on a site where Exception Replay, Dynamic Instrumentation, and Code Origin for Spans are not supported. Core APM functionality (traces, metrics, profiling, log injection) is not affected.

To stop these log messages, set the following environment variables on the Java application pod and restart the workload:

DD_EXCEPTION_REPLAY_ENABLED=false
DD_DYNAMIC_INSTRUMENTATION_ENABLED=false
DD_CODE_ORIGIN_FOR_SPANS_ENABLED=false

Alternatively, use JVM system properties:

-Ddd.exception.replay.enabled=false
-Ddd.dynamic.instrumentation.enabled=false
-Ddd.code.origin.for.spans.enabled=false

To confirm the fix, check the tracer startup JSON (DATADOG TRACER CONFIGURATION) and verify that debugger_exception_enabled, debugger_enabled, and debugger_span_origin_enabled are all false. WARN messages are rate-limited to approximately once every five minutes, so wait at least that long after restarting before confirming the messages have stopped.

Further Reading

추가 유용한 문서, 링크 및 기사:

Simplify production debugging with Datadog Exception ReplayBLOG Learn about Datadog Live DebuggerDOCUMENTATION Learn about Error Tracking MonitorsDOCUMENTATION Learn about Error Tracking for APM Backend ServicesDOCUMENTATION