Audit Trail

Overview

Audit Trail is a record of operations that lets administrators and security staff verify who in the organization is using Datadog and how. Individual users can view the flow of their own operations. The records come in 2 kinds, "request events" that mirror requests to the API, and "product-specific events" such as changes to monitors and dashboards, and you can filter and aggregate them with the same feel as the Log Explorer. The situations where you care are change management when you need to identify who deleted a missing monitor, permission cleanup when tracking role changes and logins, and when you are asked to submit evidence for an audit. It is enabled from organization settings, and the retention period is 90 days by default.

A record of operating Datadog, not of events on the monitored targets

Audit Trail is a feature that lets administrators and security teams check who in the organization is using Datadog and in what context. As an individual, you can also view the flow of your own operations (as of September 2026, Source: Datadog Audit Trail). What is easy to confuse with it here is the Event. Events record things that happened on the monitored side, such as deployments and monitor state changes. What Audit Trail records is the step before that, namely the operations that users or the API performed on Datadog itself. You will not go wrong if you separate them as: a monitor "fired" is an event, while "someone deleted" a monitor is Audit Trail's domain.

The 2 kinds of events that are recorded

The records fall into 2 kinds. One is request events, which mirror every request to the Datadog API as a record of the user. The other is product-specific events, for which the official documentation gives as examples who changed an index's retention period, who changed a pipeline or processor and when, and who changed an exclusion filter (as of September 2026). All are described as situations for tracking down the cause of a change in the bill or of a broken dashboard or monitor. From a security standpoint, the uses cited are keeping evidence of updates and deletions of important dashboards and monitors, logins, and account and role changes. The records can also be analyzed in Cloud SIEM and turned into threat detection signals.

The procedure for finding out who deleted a monitor

According to the official documentation, the Audit Trail screen has the same features as logs in the Log Explorer. What you can use for filtering are event names such as Dashboards, Monitors, and Authentication, and authentication attributes such as the person who performed the operation, the API key ID, and the email address. Facets such as Status and HTTP method are also available (as of September 2026).

The diff display is available for configuration changes to dashboards, Notebooks, and monitors. The results of your investigation can be exported to CSV, up to 100,000 records, so you can hand them over as they are when asked to submit them for an audit.

Retention is 90 days by default - prerequisites for enabling and permissions

The entry point for enabling it is Audit Trail Settings under Compliance in the organization settings. Users with the Audit Trail Write permission can perform this operation, and viewing the records requires the Audit Trail Read permission. When enabled, the retention period for audit events defaults to 90 days, and can be chosen from 3, 7, 15, 30, or 90 days. Disabling it reverts to the default of 7 days (as of September 2026). You can also optionally configure archiving; events are written out every 15 minutes to Amazon S3, Google Cloud Storage, or Azure Storage, so you can set up a configuration where your SIEM reads them. Who enabled Audit Trail is left as an event with the record "A user enabled Datadog Audit Trail," so you can confirm it from the Events Explorer.

You can also see how API keys are being used

If your organization uses Log Management, ingested logs carry a tag called datadog.api_key_uuid, which tells you which API Key collected them. The official documentation positions this as something that helps you understand how API keys are used within the organization and assists with rotation and management (as of September 2026). The Last used display in the list of application keys also appears only when Audit Trail is enabled and you have the Audit Trail Read permission (Source: API and Application Keys). If you are going to take inventory of your keys, enabling Audit Trail first gives you more material to work with. Since it is attached as a Tag, you can use it directly in aggregations on the log side as well.

Where it pays off in change management and permission cleanup

The trouble without Audit Trail is that even if you notice the fact that a setting changed, you have no way to trace who changed it and when. With it, you can confirm changes to Monitors and Dashboards with the person concerned, and if the change was unintended, look at the diff and revert it. The official documentation also gives as examples monitors that fire when a dashboard is deleted or notify you when a specific user logs in. The built-in dashboards list things such as index retention changes and pipeline changes, and you can clone them and adapt them to your own perspective. The order is to first put the recording side in order before starting the work of finely dividing permissions.