← Fundamentals / fundamentals / account / account-security

Audit Logs - version 2

Cloudflare Audit Logs are account-based. All user-initiated actions are recorded automatically across both the Cloudflare API and dashboard. System-initiated logs are also captured to reflect actions taken automatically by Cloudflare systems, such as configuration updates, background processes, or internal policy enforcement.

When a user-initiated action triggers additional automated behavior, corresponding system-initiated logs will be generated. In some cases, user-initiated logs include additional enrichments that provide more context about what was changed, offering deeper visibility into the full lifecycle of the action.

When an action occurs, it is streamed through Cloudflare's audit logging pipeline and stored. This ensures consistent visibility into activity across all products.

For more detailed information about how the user-initiated actions are logged automatically, refer to the Cloudflare Blog ↗.

Audit Logs (version 2) provide a unified and standardized system for tracking and recording actions across Cloudflare products. This system enhances transparency and accountability by offering comprehensive insights into user-initiated and system-initiated activities within your Cloudflare environment.

• Standardized logging: Audit logs are automatically generated in a consistent format across all Cloudflare services, ensuring uniformity and eliminating inconsistencies.
• Expanded product coverage: Audit Logs covers ~95% of Cloudflare products, capturing actions from key endpoints, such as /accounts, /zones, /user, and /memberships APIs.
• Granular filtering: Uniformly formatted logs allow for precise filtering by actions, actors, methods, and resources, facilitating efficient investigations.
• Enhanced context and transparency: Each log entry includes detailed context, such as the authentication method used, the interface (API or dashboard) through which the action was performed, and mappings to Cloudflare Ray IDs for improved traceability.
• Comprehensive activity capture: Audit Logs records create, update, and delete actions across all supported products. Selective logging of GET requests for sensitive read operations is planned for a future release.

• Audit logs are retained for 18 months before being deleted. No additional setup is required.

• In the Audit Logs v2 UI, queries are limited to the most recent 90 days for performance reasons. To access the full 18 months of data, use the API or Logpush.

• Enterprise customers can use Logpush to store audit logs beyond 18 months.

Audit Logs v2 supports Customer Metadata Boundary (CMB). The account-level CMB preference automatically applies to Audit Logs v2. For example, if you select eu, Audit Logs v2 uses the EU metadata boundary. You do not need to configure Audit Logs separately.

To configure CMB in the Cloudflare dashboard or via the /accounts/{account_id}/logs/control/cmb/config API, refer to Get started with Customer Metadata Boundary. CMB is part of the Data Localization Suite. Contact your account team if CMB is not enabled for your account.

You can retrieve audit logs using the Cloudflare dashboard, the API, or Logpush.

Audit Logs are available through the Cloudflare API. To retrieve audit logs, use the following endpoint:

https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit

Below is an example request to retrieve audit logs for a certain period of time along with its corresponding response. Replace the example values in the URL with your actual values:

• account_id: Your Cloudflare account identifier.
• since (required): Start date for the audit log retrieval. Accepts yyyy-mm-dd (interpreted as UTC) or RFC3339 timestamp (yyyy-mm-ddTHH:MM:SSZ).
• before (required): End date for the audit log retrieval. Same format as since.

GET https://api.cloudflare.com/client/v4/accounts/1234567890abcdef/logs/audit?since=2025-03-01T00:00:00Z&before=2025-03-26T23:59:59Z

{
	"result": [
		{
			"action": "zone.settings.change",
			"actor": {
				"email": "user@example.com",
				"id": "0987654321abcdef"
			},
			"ip": "192.0.2.1",
			"method": "PUT",
			"interface": "dashboard",
			"resources": [
				{
					"resource_id": "zone123",
					"resource_type": "zone"
				}
			],
			"timestamp": "2025-03-15T14:25:37Z"
		}
		// Additional log entries
	],
	"success": true,
	"errors": [],
	"messages": []
}

For more information refer to the API documentation ↗.

To access audit logs in the Cloudflare dashboard, go to Manage Account > Audit Logs.

To create a Logpush job:

1. In the Cloudflare dashboard, go to the Logpush page.

   Go to Logpush ↗

2. Select Create a Logpush job.

3. In Select a destination, select the destination of your choice and add the destination details.

4. In the datasets section, select the Audit Logs v2 dataset. Audit Logs v2 is an account-based dataset.

5. Once you are done configuring your logpush job, select Submit.

Resource History shows what changed on every configuration modification captured in Audit Logs. For any audit log entry, you can see the sequence of previous changes to the same resource and view a side-by-side diff of what was modified.

Resource History is available in the Cloudflare dashboard and via the Audit Logs API. It uses the audit log entries you already have. There is no additional configuration, no backend recapture, and no changes to how audit logs are generated.

For any audit log entry, Resource History retrieves every other audit log entry for the same resource, ordered chronologically. You can then pick an earlier entry from that history to see exactly which fields changed between the two.

1. Go to Manage Account > Audit Logs.
2. Open any audit log entry.
3. Select the History tab to see the full history for the resource that entry describes.
4. In the history view, select any earlier entry to see a side-by-side diff of the fields that changed between it and the current entry.

When Resource History cannot identify the underlying resource (for example, for certain system-initiated events), the dashboard shows an empty state indicating that change history is not available for that entry.

You can retrieve the change history for any audit log entry using the History endpoint. Given the id of a source audit log entry, the endpoint derives identifying filters from that entry and returns matching audit log entries within a date window you specify.

For account-scoped audit logs, use:

GET https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit/{id}/history

For organization-scoped audit logs, use:

GET https://api.cloudflare.com/client/v4/organizations/{organization_id}/logs/audit/{id}/history

The {id} path parameter is the id of the source audit log entry whose resource history you want to retrieve.

The endpoint requires three query parameters:

• action_time (required): RFC3339 timestamp of the source audit log entry's action time. Provide the action.time value from the audit log identified by {id}. This narrows the source-entry lookup window.
• since (required): Limits returned results to entries newer than this date. Accepts a date string (2024-10-30, interpreted as UTC) or an RFC3339 timestamp.
• before (required): Limits returned results to entries older than this date. Same format as since.

Optional query parameters:

• direction: desc (default) or asc.
• limit: Number of entries to return per page. Default 100.
• cursor: Pagination cursor from a previous response's result_info.cursor.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/logs/audit/$ID/history" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Each entry in result has the same shape as an entry returned by the Audit Logs list endpoint. Results are paginated using the cursor value in result_info.

The result_info.history_status field indicates the quality of resource identification used to build the history:

• exact: The source entry contained a resource URI, so the history was built from an exact resource match.
• approximate: The source entry did not contain a resource URI, so the history was built from an approximate match (other resources of the same product and type). The dashboard surfaces this state with a warning banner.
• unavailable: The source entry did not contain enough information to identify the resource. result is empty. This can happen for certain system-initiated events.

Resource History reflects the audit log entries currently retained by Audit Logs v2 (refer to Retention). Entries older than the retention window are not returned. Resource History is a query-time capability and is not exposed as additional fields in the audit_logs_v2 Logpush dataset.

Cloudflare's audit logs offer a detailed view of activity across your environment by capturing both the source of actions and the context in which they occur. These logs are categorized by who initiated the action (user or system) and whether the activity occurred within a specific account or spanned multiple accounts under the same user profile. This structure enables flexible filtering, investigation, and compliance monitoring.

Audit logs can be initiated either by users or the system. Understanding the type of actor involved helps in identifying the source and intent of actions.

Track actions performed directly by users through Cloudflare interfaces (dashboard or API). These logs capture who performed the action, when it occurred, and what resource was affected. User initiated actions can be performed by three actors:

• actor_type="user": Action was performed by an individual user.
• actor_type="Cloudflare_admin": Action was performed by Cloudflare.
• actor_type="account": Action was performed using an account API token. Refer to the Account API tokens documentation for more information.

Record changes made automatically by Cloudflare systems, without direct user input. These logs provide visibility into internal processes, automated tasks, and security events. Some entries may include associated user context for traceability (actor_type="system").

Contain events scoped to a single Cloudflare account. These logs are filterable by account ID and reflect actions within that account only. You can optionally filter events further using the resource_scope field, which specifies whether the resource is associated with a user, an account, or a zone (resource_scope ="user", resource_scope ="accounts", or resource_scope ="zones").

Reflect actions associated with a user's login (email) across multiple accounts. These logs enable cross-account tracking and can be filtered by user ID or email. They are visible on any account the user had access to at the time of the activity. User Profile Activity Logs can be filtered using resource_scope ="user".

The GET /memberships endpoint supports cross-account access. To query memberships, use the parameter resource_scope=memberships.

Contain events scoped to specific Cloudflare Organizations. These logs capture user-initiated actions performed by Org Admins through organization-level APIs.

You can retrieve Organization audit logs using either the API or the Cloudflare dashboard.

Retrievable via the Audit Logs v2 API:

GET https://api.cloudflare.com/client/v4/organizations/{organization_id}/logs/audit

To access organization audit logs in the Cloudflare dashboard, go to Organizations > (select your organization) > Manage Organization > Audit Logs.

If you are viewing account-level audit logs and the account belongs to an organization where you are an Organization Super Administrator, you can navigate to the parent organization's audit logs using the View Organization Audit Logs button.

Use the following example to get a list of audit logs for a Cloudflare account.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/logs/audit" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

{
	"errors": [
		{
			"message": "message"
		}
	],
	"result": [
		{
			"account": {
				"id": "4bb334f7c94c4a29a045f03944f072e5",
				"name": "Example Account"
			},
			"action": {
				"description": "Add Member",
				"result": "success",
				"time": "2024-04-26T17:31:07Z",
				"type": "create"
			},
			"actor": {
				"id": "f6b5de0326bb5182b8a4840ee01ec774",
				"context": "dash",
				"email": "alice@example.com",
				"ip_address": "198.41.129.166",
				"token_id": "token_id",
				"token_name": "token_name",
				"type": "user"
			},
			"raw": {
				"cf_ray_id": "8e9b1c60ef9e1c9a",
				"method": "POST",
				"status_code": 200,
				"uri": "/accounts/4bb334f7c94c4a29a045f03944f072e5/members",
				"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Safari/605.1.15"
			},
			"resource": {
				"id": "id",
				"product": "members",
				"request": {},
				"response": {},
				"scope": {},
				"type": "type"
			},
			"zone": {
				"id": "id",
				"name": "example.com"
			}
		}
	],
	"result_info": {
		"count": "1",
		"cursor": "ASqdKd7dKgxh-aZ8bm0mZos1BtW4BdEqifCzNkEeGRzi_5SN_-362Y8sF-C1TRn60_6rd3z2dIajf9EAPyQ_NmIeAMkacmaJPXipqvP7PLU4t72wyqBeJfjmjdE="
	},
	"success": true
}

The actor represents who performed the action. It includes identity attributes like user ID, email address, IP address, and the type of actor (user, account, Cloudflare_admin, or system). It also includes the context used to initiate the action:

• api: The action was performed through the API. The specific credential type was not recorded.
• api_key: The action was authenticated with a Cloudflare Global API Key.
• api_token: The action was authenticated with an API token.
• dash: The action was performed through the Cloudflare dashboard.
• oauth: The action was authenticated with an OAuth token.
• origin_ca_key: The action was authenticated with an Origin CA key.

The action field captures the nature of the event and whether it was successful. It includes a high-level type (e.g., create, update, delete), a specific description (such as SSO_LOGIN), the timestamp of when the action occurred, and the result (success or failure).

view actions correspond to GET requests. These are defined in the schema but not currently captured in Audit Logs. Selective GET logging for sensitive read operations is planned for a future release.

This field refers to the Cloudflare account under which the action was executed. It includes a unique account ID and a human-readable account name to help associate activity with a customer environment.

The resource identifies the object impacted by the action. It includes the resource type, the unique resource ID, the scope (user, account, or zone), and optionally the product associated with the change.

This is a unique identifier for the log record itself. It can be used for deduplication, correlation, or referencing specific actions during investigations.