---
title: Audit trail log delivery
description: Configure and explore audit trail log delivery for Elastic Cloud Serverless, including ignore filters, destinations, data streams, and investigation recipes.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8269/deploy-manage/monitor/log-delivery/audit-trail
products:
  - Elastic Cloud Serverless
applies_to:
  - Elastic Cloud Serverless: Preview
---

# Audit trail log delivery
Audit trail is the first log type available for [log delivery](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8269/deploy-manage/monitor/log-delivery) in Elastic Cloud Serverless. Enabling it delivers audit logs to your selected destination project so you can track and investigate organization actions in the source project.

## What's included

An audit trail includes the following events:
- **Elastic Cloud and organization administration:** Sign-ins; membership and IAM; and project settings.
- **Project activity:** Elasticsearch and Kibana activity, including index, template, and pipeline lifecycle; data searches, reads, and writes; and UI access.

Audit trail delivery is applicable to Serverless projects, so Elastic Cloud Hosted fields like `node.*` and `host.*` are not included.

### Why deliver an audit trail

Delivering an audit trail into a project lets you investigate end-to-end activity in one place. For example, you can:
- Trace failed or successful sign-ins for a user
- Review membership, IAM, or project-admin changes
- Investigate access denied on an index pattern
- Track create, update, or delete actions on indices, templates, or pipelines
- Detect changes or deletions of Kibana saved objects such as detection rules
- Determine who searched a sensitive index
- Follow a user journey across `service.name` values for the same `user.name` and time window


## Set up delivery for audit trail

Complete the following steps to configure audit trail log delivery in your project.

### Before you begin

You must have the **Admin** or **Editor** [role](/elastic/docs-content/pull/8269/deploy-manage/users-roles/cloud-organization/user-roles#general-assign-user-roles-table) on the source project.

### Configuration steps

1. On your Elastic Cloud homepage, find the project that should be the source of your log deliveries and select **Manage**.
2. From the navigation menu, select **Log delivery**.
3. For **Audit trail**, complete the following fields.
   - In the **Destination** column, select an Elastic Security Serverless or Elastic Observability Serverless project to receive the logs.
  <tip>
  Since audit logs are security data, we recommend selecting a Elastic Security Serverless project as the destination for your audit trail.
  </tip>
- Select [ignore filters](#audit-trail-ignore-filters) to exclude certain events before delivery. Leave the list empty only if you want to deliver all events for that log type.
- Switch the toggle to **Enabled**.
4. Select **Save**.


### Audit trail ignore filters

Apply ignore filters to exclude certain events from being delivered. Refer to [Log delivery in Elastic Cloud Serverless > Ignore filters](/elastic/docs-content/pull/8269/deploy-manage/monitor/log-delivery#ignore-filters) to learn more about their impact on your delivery volume and bill.
The following table describes which ignore filters are available for the audit trail log type and when to select them.

| Name                                | When to select                                                                                                                                                                                                                                              |
|-------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Ignore data searches and reads      | Select to exclude the highest-volume events on search-heavy projects. Do not select if you need evidence of who searched or read data.                                                                                                                      |
| Ignore data writes                  | Select when you want configuration and object-change evidence without ingest and bulk write volume.                                                                                                                                                         |
| Ignore successful sign-ins          | Select for security operations or minimal profiles that focus on failures. Do not select if you need successful sign-in accountability. Applies to authentication events in the audit trail, including Elastic Cloud and organization signals when present. |
| Ignore routine user and role checks | Select for security operations or minimal profiles that focus on failures. Do not select if you need IAM accountability. Applies to IAM-related events in the audit trail, including Elastic Cloud and organization signals when present.                   |
| Ignore UI requests                  | Select to exclude read-only UI navigation noise. Saved object mutations are still delivered.                                                                                                                                                                |


#### Ignore filter combinations

In the following table, find the recommended combination of filters to select for typical use cases.

| Typical use                                | Ignore filters to select                                                         |
|--------------------------------------------|----------------------------------------------------------------------------------|
| General production                         | • Ignore data searches and reads• Ignore UI requests                             |
| Change accountability without search noise | • Ignore data searches and reads                                                 |
| Failure-oriented monitoring                | • Ignore data searches and reads• Ignore UI requests• Ignore successful sign-ins |
| Change management                          | • Ignore data searches and reads• Ignore UI requests• Ignore data writes         |
| Dev or sandbox                             | All                                                                              |
| Maximum end-to-end evidence                | None                                                                             |


## Explore delivered logs

Use the AutoOps [Storage Tier](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8269/deploy-manage/monitor/autoops/storage-tier-view-autoops-serverless) view on the destination project to monitor your ingest rate and storage retained.
Use Discover or ES|QL to explore delivered audit trail logs in the following locations on your destination project:

| Data stream or index pattern               | Contents                                                                            |
|--------------------------------------------|-------------------------------------------------------------------------------------|
| `logs-*.audit.otel-*`                      | All audit logs                                                                      |
| `logs-org.audit.otel-elastic_cloud`        | Organization-level audit logs (administration, configuration, billing, and similar) |
| `logs-serverless.audit.otel-elastic_cloud` | Project-level audit logs (Elasticsearch, Kibana, and Elastic Cloud project signals) |

<warning>
  Restrict who can access these locations in your destination project, because logs might include user identifiers and client IPs.
</warning>


### Example queries

Explore the following examples of what you can investigate with your delivered audit logs. Run each query against `logs-*.audit.otel-*` in Discover.

#### Failed or denied activity

```esql
FROM logs-*.audit.otel-*
| WHERE event.outcome == "failure" OR event.action IN ("access_denied", "authentication_failed")
| KEEP @timestamp, user.name, user.id, event.action, event.outcome, source.ip, project.id, service.name
| SORT @timestamp DESC
| LIMIT 100
```


#### Kibana and saved-object changes

```esql
FROM logs-*.audit.otel-*
| WHERE event.action IN (
    "rule_create", "rule_delete", "rule_update",
    "saved_object_create", "saved_object_delete", "saved_object_update",
    "connector_create", "connector_delete", "connector_update",
    "space_update"
  )
| KEEP @timestamp, user.name, event.action, kibana.space.id, kibana.saved_object.type, kibana.saved_object.id, service.name
| SORT @timestamp DESC
| LIMIT 100
```


#### Access denied on indices

```esql
FROM logs-*.audit.otel-*
| WHERE event.action == "access_denied"
| KEEP @timestamp, user.name, elasticsearch.audit.action, elasticsearch.audit.indices, source.ip, service.name
| SORT @timestamp DESC
| LIMIT 100
```


#### Who is changing configuration and objects

```esql
FROM logs-*.audit.otel-*
| WHERE event.type IN ("creation", "change", "deletion")
| STATS events = COUNT(*) BY user.name, event.action, service.name
| SORT events DESC
| LIMIT 20
```


#### Who searched a sensitive index

Do not select the **Ignore data searches and reads** filter for this query. Replace `<INDEX_PATTERN>` with the index or pattern to watch.
```esql
FROM logs-*.audit.otel-*
| WHERE event.action == "access_granted"
  AND elasticsearch.audit.indices LIKE "<INDEX_PATTERN>"
| KEEP @timestamp, user.name, user.id, elasticsearch.audit.action, elasticsearch.audit.indices, source.ip, service.name
| SORT @timestamp DESC
| LIMIT 100
```