Overview

The Datadog extension for VS Code and Cursor brings Datadog to your code editor to accelerate your development.

The extension includes these features:

• Model Context Protocol (MCP) Server: Connect the AI agent to production telemetry, tools, and contexts from Datadog.

• Log Annotations: Gauge log volumes and search logs from your code.

• Code Insights: Stay informed about runtime errors, vulnerabilities, and flaky tests without leaving the code.

• View in IDE: Jump directly from code references in Datadog to your source files.

• Code Security: Detect and fix security vulnerabilities, bugs, and exposed secrets before you commit changes.

• Exception Replay: Debug your production code.

• Live Debugger: Add non-breaking, auto-expiring logpoints to running services to capture runtime data without redeploying.

• Fix in Chat: Fix code errors, vulnerabilities, and flaky tests with AI-powered suggestions and explanations.

Unless stated otherwise, all extension features are available for both VS Code and any other IDEs based on VS Code forks, such as Cursor.

Requirements

• Datadog account: Most features require a Datadog account.

  • New to Datadog? Learn more about Datadog's monitoring and security tools and sign up for a free trial.
  • If your organization uses a custom sub-domain such as myorg.datadoghq.com, you must indicate it using the datadog.connection.oauth.setup.domain setting in the IDE.

• Git: The extension works better when Git is enabled in the IDE. Ensure this is enabled by checking the git.enabled setting.

MCP Server setup

The extension includes access to the Datadog Model Context Protocol (MCP) Server. Enable the MCP Server to enhance your IDE's AI capabilities with your specific Datadog environment.

In Cursor

Install the Datadog Cursor Plugin from the Cursor marketplace. The plugin configures the Datadog MCP Server in Cursor automatically.

In VS Code

1. Open the chat panel, select agent mode, and click the Configure Tools button.
2. Find the Datadog server and tools in the list and check the boxes to enable them (expand or refresh if necessary).

Log annotations

Use Log Annotations to gauge the volume of logs generated by a given log line in your code. The extension adds annotations above your code to detected logging patterns that match log records in Datadog. Click an annotation to open the Log Explorer in Datadog and view the matching logs.

You can also search Datadog logs from within VS Code. Select any text in the code editor, then right-click and select Datadog > Search Logs With Selected Text.

Code Insights

Code insights keep you informed with Datadog-generated insights that are relevant to your code base:

• Runtime errors collected by Error Tracking
• Code and library vulnerabilities reported by Code Security
• Flaky tests detected by Test Optimization

The extension identifies errors and vulnerabilities in the code with colored squiggles; hover over the line for more details.

The Code Insights view in the Datadog sidebar lists all the issues found in the repository. Select an item to view the full insight, and use the links to jump to the related source code location or open the code insight in Datadog.

You can group code insights by kind, file, priority, or service. You can also ignore individual code insights and set filters to view the ones you're most interested in.

For specific insights about the file currently open in the active editor, check the File Insights view in the IDE's file explorer. This view also lists issues discovered by Code Security within the file.

View in IDE

This feature is only available for VS Code and Cursor. Other forks of VS Code are not supported.

The View in VS Code or View in Cursor feature provides a link from Datadog directly to your source files. Look for the button next to frames in stack traces displayed in the UI (for example, in Error Tracking):

You can also use this feature to open your source files from an insight (such as an error from Error Tracking):

To use this feature, first configure source code integration for your service.

Code Security

The Code Security features analyze your code locally to detect and fix security issues and vulnerabilities before you commit your changes. The extension supports two complementary scan types: Static Code Analysis and Secret Scanning.

Static Code Analysis

Static Code Analysis analyzes your source files against predefined rules to catch security vulnerabilities, bugs, and maintainability issues.

The extension runs Static Code Analysis rules on the source files you have open in your workspace. Static Code Analysis supports scanning for many programming languages. For a complete list, see Static Code Analysis Rules. Issues are shown in the source code editor, and you can directly apply suggested fixes.

Get started with Static Code Analysis

When you start editing a source file, the extension checks for static-analysis.datadog.yml at your source repository's root. It prompts you to create it if necessary.

After you create the configuration file, the analyzer runs automatically in the background whenever you open a file. If you need to enable Static Code Analysis for a particular language, search for the command Datadog: Configure Static Analysis Languages in the command palette (Shift + Cmd/Ctrl + P).

You can also run a batch analysis for individual folders and even the entire workspace. In the IDE's file explorer view, right-click a folder and select Datadog Code Security > Analyze Folder or Analyze Workspace.

Rule editor

Write and test custom Static Code Analysis rules without leaving your IDE. Use the Datadog DDSA Rule Editor to design detection logic for internal standards, security patterns, or maintainability checks specific to your codebase.

To open the rule editor, run the Datadog: New DDSA Rule command from the command palette (Shift + Cmd/Ctrl + P), or right-click a YAML file and select Datadog Code Security > Open in DDSA Rule Editor.

Secret Scanning

Secret Scanning detects exposed credentials — API keys, tokens, and passwords — in your source files before you commit them. File contents are scanned locally against rules fetched from your Datadog organization, and findings appear in the editor as you type.

Secret Scanning is enabled by default and runs in the background whenever you open a source file. No local configuration is required — scan rules are fetched from the Datadog backend. All text files are scanned; binary files are skipped automatically.

You can also scan an entire folder or workspace at once. In the IDE's file explorer view, right-click a folder and select Datadog Code Security > Analyze Folder or Analyze Workspace.

Secret Scanning requires you to be signed in to Datadog, because detection rules are fetched from your Datadog organization.

Review findings

Detected secrets are shown in three places:

• Inline in the editor: each finding appears as an underline on the detected secret, with severity derived from the rule's priority.
• Problems panel: all findings are listed with the source Datadog.
• File Insights view: findings are grouped alongside other Code Security issues.

Suppress a finding

To suppress an individual detection, use the code action for the flagged secret to insert a no-dd-secrets comment on the line above. The comment suppresses all secret findings on the immediately following line.

Turn Secret Scanning on or off

To toggle Secret Scanning, run the Datadog: Turn on Secret Scanning or Datadog: Turn off Secret Scanning command from the command palette (Shift + Cmd/Ctrl + P), or change the datadog.codeSecurity.setup.secretScanning.enabled setting.

Exception Replay

Exception Replay allows you to inspect the stack trace frames of any Error Tracking code insight and get information about the values of the variables of the code running in production.

To access this feature, you must enable Error Tracking Exception Replay on Datadog.

After the feature has been enabled, you can see an Exception Replay button next to the stack trace section of any instrumented Error Tracking code insight. Click the button to:

• Access all the information Datadog has about the different frames.
• Navigate through the production code.
• Review the value of the different variables involved.

Select an Error Tracking code insight from the Code Insights view. Go to the stack trace and click the Exception Replay button. The IDE shows a new activity with two new views:

• Variables: Displays the variables related to a particular stack trace frame.
• Stack Trace: Lists the stack frames for navigation.

Select a stack trace frame and inspect the values of all the variables that Datadog captured from your production code.

Live Debugger

The Live Debugger lets you add logpoints — auto-expiring, non-breaking breakpoints — to your running services to collect information for debugging. Logpoints are set dynamically, so you don't need to redeploy your code to investigate an issue. Logpoints are grouped into sessions, and you can activate, edit, deactivate, or delete sessions (or individual logpoints) at any time. All sessions and logpoints automatically deactivate after 60 minutes, and log events are rate-limited to one execution per second.

To use this feature, your service must be set up for Datadog Dynamic Instrumentation, and remote code is matched to your local files using Source Code Integration.

The Datadog Live Debugger activity

The extension contributes a dedicated Datadog Live Debugger activity to the IDE sidebar, with the following views:

• Sessions: lists existing sessions and lets you activate, deactivate, delete, or refresh them, and open them in the Datadog UI. The view can be filtered to show only your sessions, only active sessions, and/or only sessions whose service repositories are open in the workspace.
• Logpoints: lists the logpoints belonging to the selected session. From here you can enable, disable, edit, or delete a logpoint, jump to its source location, copy its id or link, or open it in Datadog.
• Log Events: shows recent log events generated by the selected logpoint. You can open events in the Datadog UI or use Generate Unit Test to turn captured runtime values into a unit test (see below).
• Variables: shows the variables captured for the selected log event as a searchable tree. You can copy values or jump to the variable's source location.
• Logpoint Editor: a webview form used to create or edit a logpoint (service, environment, message template, condition, capture variables depth).

Source editor integration

For lines that have a logpoint defined in the current session, the extension shows a status icon in the editor gutter and a code lens above the line, and lets you act on the logpoint from the line-number context menu:

• Right-click on the line number of any line of code and select Datadog Live Debugger > Create Logpoint to start creating a logpoint on that line.
• For a line that already has a logpoint, the same submenu offers Edit, Delete, and either Enable or Disable depending on the logpoint's current state.
• Click the code lens above the line to reveal the logpoint in the Live Debugger views.

Creating a logpoint

To add a logpoint, right-click the line number for a line of code in the source editor and select Datadog Live Debugger > Create Logpoint. The logpoint is added to the current session, or a new session is created if needed.

The Logpoint Editor webview shows the following fields:

• Service and Environment: target the service and environment where the logpoint will run. The list of services is filtered by the current file's language to show only compatible services.
• Message template: descriptive text with variable references using the Dynamic Instrumentation expression language. The message is built from the runtime state immediately before the line of code is executed. Generated messages automatically pass through the Dynamic Instrumentation Sensitive Data Scanner.
• Condition (optional): when defined, a log event is emitted only if the expression evaluates to true. Use it to capture events based on runtime state (for example, a particular user or transaction id).
• Capture variables depth: controls how deeply hierarchical data structures are traversed when capturing runtime values. Higher values provide more useful information but require more capacity.

The editor warns you when no service or environment matches the file's language, or when the remote service is associated with a different repository than the local workspace — you can still create the logpoint in those cases.

Local and remote versions

The remote running code may be a different revision compared to the source you are editing. The extension uses Git commit information to map line numbers from your local file to the remote revision, so logpoints land on the correct line even if the remote is on a different commit. This requires your service to be tagged with Git information.

Tip: checking out locally the same revision that is running remotely shows you the same code in the IDE that is running in production, which simplifies the live debugging experience — but it isn't required.

Editing, enabling, disabling, and deleting

• Edit: right-click a logpoint (in the editor or in the Logpoints view) and select Edit to update its message template, condition, or capture depth. Changing the service or environment requires deleting the logpoint and creating a new one. Saving an edit also extends the expiration to 60 minutes.
• Enable / Disable: toggle a logpoint or a whole session from the views or the line-number context menu. Re-enabling a logpoint extends its expiration to 60 minutes.
• Delete: deleting a logpoint does not delete the events it has already generated. Deleting a session deletes all of its logpoints and cannot be undone. The extension asks for confirmation before deleting (you can suppress these prompts in the extension settings).

The gutter icon reflects the current status of each logpoint:

Icon	Status	Meaning
	Active	The logpoint is installed and emits log events when the line of code is about to run.
	Warning	The logpoint may not be generating events yet. This is shown when the backend hasn't processed a recent change (WAITING) or no tracer agents are reporting for the targeted service (NO_AGENTS).
	Error	The logpoint is not generating events because of an error, or its status is unknown.
	Disabled	The logpoint is inactive — either you disabled it manually or it has expired.

Generate a unit test from a log event

From the Log Events view, the Generate Unit Test action sends the runtime values captured by a logpoint (variables and arguments) to the chat agent with a prompt to produce a unit test that reproduces the captured state. This is useful to turn a real production event into a regression test.

Fix in Chat

The Fix in Chat button appears in several contexts when the extension identifies errors or issues. Click the button to generate an AI chat prompt that summarizes the problem, includes relevant details and context, and gives specific instructions for the agent.

License

Read the End-User License Agreement carefully before downloading or using this extension.

Data and Telemetry

Datadog collects certain information about your usage of this IDE, including how you interact with it, whether errors occurred while using it, what caused those errors, and user identifiers in accordance with the Datadog Privacy Policy and Datadog's VS Code extension EULA. This data is used to help improve the extension's performance and features, including transitions to and from the extension and the applicable Datadog login page for accessing the Services.

If you don't wish to send this data to Datadog, you can disable this at any time in the extension's settings: Datadog > Telemetry > Setup > Enable Telemetry and select disabled.

The Datadog extension also honors the VS Code telemetry setting.

Help and Feedback

Help us improve the extension by sharing your feedback using the feedback form, email us at team-ide-integration@datadoghq.com, or create an issue in our public repository.

Check out the issues section to discover known issues.

Do you use Cursor, or another fork of VS Code? Find the extension on the Open VSX Registry.