Observability

Cloudflare Observability

import { CardGrid, Feature, LinkTitleCard } from "~/components";

Cloudflare provides observability tools across its network and developer products. Use this page to find the documentation for your task.

Explore observability tools

<Feature header="Investigate logs" href="/observability/logs/" cta="Explore logs"

Store and investigate Workers and Cloudflare service logs.

<Feature header="Trace a request" href="/observability/traces/" cta="Explore traces"

See how a request moves through Cloudflare and your Workers, and where time is spent.

<Feature header="Monitor errors" href="/workers/observability/issues/" cta="Explore Workers Issues"

Group recurring Workers failures into issues and route them to your team.
Analyze traffic, security, performance, and product data. Configure alerts and where they are delivered.

<Feature header="Export telemetry" href="/observability/export/" cta="Explore export options"

Send logs and Workers telemetry to external destinations.

<Feature header="Build dashboards" href="/analytics/custom-dashboards/" cta="Explore dashboards"

Build charts from supported Analytics datasets and Log Explorer datasets.

Pricing and availability

Review ingestion and storage pricing for logs and traces.

Export

import { CardGrid, LinkTitleCard } from "~/components";

Use Logpush for logs generated by Cloudflare products. Use OpenTelemetry for logs and traces from Cloudflare Observability and Workers.

Send Cloudflare logs to supported storage and analytics destinations. Send Cloudflare Traces, Workers traces, and Workers logs to an OpenTelemetry destination.

Export to Axiom

import { DashButton, Steps } from "~/components";

Trace view with timing information displayed on a timeline

This guide configures Axiom to receive Cloudflare traces and logs.

Prerequisites

Before you begin, you need an active Axiom account. You also need Cloudflare logs or traces to export.

1. Create a dataset

Skip this step if you already have a dataset.

  1. Log in to your Axiom account.
  2. Go to Datasets.
  3. Select New Dataset.
  4. Enter a name, such as cloudflare-otel.
  5. Select Create Dataset.

2. Get an Axiom API token

  1. Go to Settings > API Tokens.
  2. Select Create API Token.
  3. Enter a descriptive name, such as cloudflare-otel.
  4. Select the Ingest permission.
  5. Select datasets for the token, or select All Datasets.
  6. Select Create.
  7. Copy and securely store the API token.

The API token starts with xaat-.

3. Configure a Cloudflare Observability destination

Axiom provides separate OpenTelemetry Protocol (OTLP) endpoints for traces and logs:

  1. In the Cloudflare dashboard, go to Observability > Destinations.

  2. Select Add destination.

  3. Configure the destination:

    • Destination name: Enter axiom-traces or axiom-logs.
    • Destination type: Select Traces or Logs.
    • OTLP endpoint: Enter the matching Axiom endpoint.

  4. Add an authentication header:

    • Header name: Authorization
    • Header value: Bearer <YOUR_API_TOKEN>

  5. Add the dataset header:

    • Header name: X-Axiom-Dataset
    • Header value: Your dataset name

  6. Select Save.

4. Enable export

Creating a destination does not start exporting telemetry. To export Workers Logs or Workers Traces, configure OpenTelemetry export for your Worker. To export Cloudflare Traces, configure export for your domain.

Data may take several minutes to appear in Axiom.

Export to Grafana Cloud

import { DashButton, Steps } from "~/components";

Grafana Cloud provides visualization, alerting, and telemetry analytics. It accepts Cloudflare telemetry through the OpenTelemetry Protocol (OTLP).

Export Cloudflare traces to Grafana Tempo and logs to Grafana Loki.

Grafana Tempo trace view showing a distributed trace for a service with multiple spans including fetch requests, durable object subrequests, and queue operations, with timing information displayed on a timeline

This guide configures Grafana Cloud to receive Cloudflare traces and logs.

Prerequisites

Before you begin, you need an active Grafana Cloud account. You also need Cloudflare logs or traces to export.

1. Get your OpenTelemetry credentials

  1. Log in to the Grafana Cloud portal.
  2. From your organization home page, go to Connections > Add new connection.
  3. Search for OpenTelemetry, then select OpenTelemetry (OTLP).
  4. Select Quickstart, then select JavaScript.
  5. Select Create a new token.
  6. Enter a token name, such as cloudflare-otel.
  7. Select Create token, then select Close.
  8. Copy the OTEL_EXPORTER_OTLP_ENDPOINT value from Environment variables.
  9. Copy the OTEL_EXPORTER_OTLP_HEADERS value from the same block.

2. Configure Cloudflare Observability destinations

  1. In the Cloudflare dashboard, go to Observability > Destinations.

  2. Select Add destination.

  3. Enter a descriptive destination name, such as grafana-traces.

  4. For Destination type, select Traces or Logs. Create a separate destination for each type you export.

  5. Enter the Grafana OTLP endpoint for your telemetry type:

    • Traces: Append /v1/traces to the endpoint.
    • Logs: Append /v1/logs to the endpoint.

  6. Add the Grafana authentication header:

    • Header name: Authorization
    • Header value: The Basic authentication value from Grafana

  7. Select Save.

The endpoint resembles https://otlp-gateway-prod-us-east-2.grafana.net/otlp.

3. Enable export

Creating a destination does not start exporting telemetry. To export Workers Logs or Workers Traces, configure OpenTelemetry export for your Worker. To export Cloudflare Traces, configure export for your domain.

Data may take several minutes to appear in Grafana Cloud.

Export to Honeycomb

import { DashButton, Steps } from "~/components";

Honeycomb is an observability platform for high-cardinality telemetry data. Export Cloudflare telemetry to Honeycomb to query logs, inspect traces, and create dashboards.

Trace view including POST request, fetch operations, durable object subrequest, and queue send, with timing information displayed on a timeline

This guide configures Honeycomb to receive Cloudflare traces and logs.

Prerequisites

Before you begin, you need an active Honeycomb account. You also need Cloudflare logs or traces to export.

1. Get your Honeycomb API key

  1. Log in to your Honeycomb account.
  2. From your profile menu, select Team Settings.
  3. Select Environments, then select the gear icon.
  4. Select an environment or create one.
  5. Under API Keys, select Create Ingest API Key.
  6. Enter a descriptive name, such as cloudflare-otel.
  7. Select Can create services/datasets.
  8. Select Create.
  9. Copy and securely store the API key.

The API key starts with hcaik_.

2. Configure Cloudflare Observability destinations

Honeycomb provides separate OpenTelemetry Protocol (OTLP) endpoints for traces and logs:

Configure a traces destination

  1. In the Cloudflare dashboard, go to Observability > Destinations.

  2. Select Add destination.

  3. Configure the destination:

    • Destination name: honeycomb-traces
    • Destination type: Traces
    • OTLP endpoint: https://api.honeycomb.io/v1/traces
    • Custom header name: x-honeycomb-team
    • Custom header value: Your Honeycomb API key

  4. Select Save.

Configure a logs destination

  1. Select Add destination again.
  2. Configure the destination:
    • Destination name: honeycomb-logs
    • Destination type: Logs
    • OTLP endpoint: https://api.honeycomb.io/v1/logs
    • Custom header name: x-honeycomb-team
    • Custom header value: Your Honeycomb API key
  3. Select Save.

3. Enable export

Creating a destination does not start exporting telemetry. To export Workers Logs or Workers Traces, configure OpenTelemetry export for your Worker. To export Cloudflare Traces, configure export for your domain.

Data may take several minutes to appear in Honeycomb.

OpenTelemetry export

import { DashButton, Steps } from "~/components";

Cloudflare exports telemetry to destinations that support the OpenTelemetry Protocol (OTLP). Use these destinations with Cloudflare telemetry and your existing observability tools.

Supported telemetry

You can export these telemetry types:

Available destinations

These endpoint formats cover common observability providers. Check your provider documentation for current authentication requirements.

Provider Traces endpoint Logs endpoint
Honeycomb https://api.honeycomb.io/v1/traces https://api.honeycomb.io/v1/logs
Grafana Cloud https://otlp-gateway-<REGION>.grafana.net/otlp/v1/traces https://otlp-gateway-<REGION>.grafana.net/otlp/v1/logs
Firetiger https://ingest.cloud.firetiger.com/v1/traces https://ingest.cloud.firetiger.com/v1/logs
Axiom https://api.axiom.co/v1/traces https://api.axiom.co/v1/logs
Sentry https://<HOST>/api/<PROJECT_ID>/integration/otlp/v1/traces https://<HOST>/api/<PROJECT_ID>/integration/otlp/v1/logs
Sematext https://otlp-receiver.sematext.com (US), https://otlp-receiver.eu.sematext.com (EU) https://otlp-receiver.sematext.com (US), https://otlp-receiver.eu.sematext.com (EU)
PostHog Not supported https://<REGION>.i.posthog.com/i/v1/logs
Datadog https://cloudflare.integrations.otlp.<DD_SITE>/v1/traces https://cloudflare.integrations.otlp.<DD_SITE>/v1/logs
New Relic https://otlp.nr-data.net/v1/traces https://otlp.nr-data.net/v1/logs
Splunk Observability https://ingest.<REALM>.signalfx.com/v2/trace/otlp N/A
Splunk Platform http://splunk.internal:4318/v1/traces http://splunk.internal:4318/v1/logs
SigNoz https://ingest.<region>.signoz.cloud:443/v1/traces https://ingest.<region>.signoz.cloud:443/v1/logs

:::note[Authentication] Most providers require authentication headers. Check your provider documentation for specific requirements. :::

Create a destination

Create an account-level Cloudflare Observability destination first.

:::note[Protocol] Cloudflare does not support the binary format for OTLP ingestion. :::

Observability Destinations dashboard showing configured destinations for Grafana and Honeycomb with their respective endpoints and status

  1. In the Cloudflare dashboard, go to Observability > Destinations.

  2. Select Add destination.

  3. Configure the destination:

    • Destination name - Enter a descriptive name, such as grafana-traces.
    • Destination type - Select Traces or Logs.
    • OTLP endpoint - Enter the provider endpoint for your telemetry type.
    • Custom headers - Add any provider authentication headers.

  4. Select Save.

Edit Destination dialog showing configuration for Honeycomb tracing with destination name, type selection, OTLP endpoint, and custom headers

Enable export for Cloudflare Traces

Add the destination under Export destinations in your domain settings. Refer to Cloudflare Traces configuration.

Enable OpenTelemetry export for your Worker

Configure and redeploy your Worker after creating a destination. Refer to Workers OpenTelemetry export.

Check destination status

The dashboard shows each destination delivery status. The status reflects the most recent delivery attempt.

Status Description Troubleshooting
Last: n minutes ago Cloudflare delivered data recently. No action required
Never run Cloudflare has not delivered data. Check source traffic, export settings, and sampling rates
Error Cloudflare could not deliver data. Check the OTLP endpoint and authentication headers

Known limitations

Some providers do not support every OTLP telemetry type. Check the available destinations and your provider documentation.

Export to PostHog

import { DashButton, Steps } from "~/components";

PostHog provides product analytics, logs, and error tracking. Export Cloudflare logs to correlate them with sessions and events.

PostHog logs view with attributes expanded and a timeline view at the top

This guide configures PostHog to receive Cloudflare logs.

Prerequisites

Before you begin, you need:

1. Get your PostHog project API key

  1. Log in to your PostHog account.
  2. Go to Project settings.
  3. Find Project API key in the project details.
  4. Copy the project API key.

The project API key starts with phc_.

2. Select your PostHog endpoint

PostHog uses different endpoints for each data region:

Region Logs endpoint
US (default) https://us.i.posthog.com/i/v1/logs
EU https://eu.i.posthog.com/i/v1/logs

Find your region in your PostHog project settings. Your PostHog URL also contains us or eu.

3. Configure a Cloudflare Observability destination

:::caution PostHog accepts logs through its OpenTelemetry Protocol (OTLP) endpoint. It does not accept traces through OTLP. :::

  1. In the Cloudflare dashboard, go to Observability > Destinations.

  2. Select Add destination.

  3. Configure the destination:

    • Destination name: posthog-logs
    • Destination type: Logs
    • OTLP endpoint: Your PostHog regional logs endpoint
    • Custom header name: Authorization
    • Custom header value: Bearer <YOUR_PROJECT_API_KEY>

  4. Select Save.

Cloudflare destination configuration for PostHog logs with destination name, type selection, OTLP endpoint, and custom headers

4. Enable export

Creating a destination does not start exporting logs. To export Workers Logs, configure OpenTelemetry export for your Worker. PostHog does not support Workers Traces or Cloudflare Traces through OTLP.

5. View logs in PostHog

  1. Log in to your PostHog account.
  2. Go to Logs.
  3. Review exported severity levels, timestamps, and attributes.

You can filter logs by severity, time range, attributes, and keywords.

Troubleshooting

Logs do not appear in PostHog

  1. Verify that the API key starts with phc_.
  2. Confirm that the endpoint matches your PostHog region.
  3. Check the destination status in the Cloudflare dashboard.
  4. Check whether sampling excludes the expected logs.

Fix authentication errors

Confirm that the Authorization value includes the Bearer prefix. Also verify that the project API key remains active.

Alternatively, add the token to the endpoint query string: https://us.i.posthog.com/i/v1/logs?token=<YOUR_PROJECT_API_KEY>.

Export to Sentry

import { DashButton, Steps } from "~/components";

Sentry provides distributed tracing, logs, and application monitoring. Export Cloudflare telemetry to query data and create alerts or dashboards.

Sentry trace view with timing information displayed on a timeline

This guide configures Sentry to receive Cloudflare traces and logs.

Prerequisites

Before you begin, you need an active Sentry account. You also need Cloudflare logs or traces to export.

1. Create a Sentry project

Skip this step if you already have a project.

  1. Log in to your Sentry account.
  2. Go to Insights > Projects.
  3. Select New Project.
  4. Complete the project form, then select Create Project.

2. Get your Sentry OTLP endpoints

Sentry provides separate OpenTelemetry Protocol (OTLP) endpoints for traces and logs:

  1. In Sentry, go to Settings > Projects.
  2. Select your project.
  3. Under SDK Setup, select Client Keys (DSN).
  4. Copy the OTLP endpoints and authentication header.

For endpoint details, refer to Sentry OTLP documentation.

3. Configure Cloudflare Observability destinations

In the Cloudflare dashboard, go to Observability > Destinations.

Configure a traces destination

  1. Select Add destination.
  2. Configure the destination:
    • Destination name: sentry-traces
    • Destination type: Traces
    • OTLP endpoint: Your Sentry OTLP traces endpoint
    • Custom header name: x-sentry-auth
    • Custom header value: sentry sentry_key=<SENTRY_PUBLIC_KEY>
  3. Select Save.

Configure a logs destination

  1. Select Add destination.
  2. Configure the destination:
    • Destination name: sentry-logs
    • Destination type: Logs
    • OTLP endpoint: Your Sentry OTLP logs endpoint
    • Custom header name: x-sentry-auth
    • Custom header value: sentry sentry_key=<SENTRY_PUBLIC_KEY>
  3. Select Save.

4. Enable export

Creating a destination does not start exporting telemetry. To export Workers Logs or Workers Traces, configure OpenTelemetry export for your Worker. To export Cloudflare Traces, configure export for your domain.

Data may take several minutes to appear in Sentry.

Datasets

import { DashButton } from "~/components";

Cloudflare Observability supports logs from the products listed in the table. Turn on each dataset in the location shown under Enablement. Log Explorer (Legacy) datasets appear in Logs once your account has the Log Explorer add-on and the dataset is turned on. Event sizes are estimates and vary by record.

You can also query sampled analytics datasets for your zones in Logs without turning anything on.

Supported datasets

Dataset Identifier Enablement Average event size Default retention
Workers workers On Worker 4.84 KB 7 days
Containers containers On Worker 1.88 KB 7 days
R2 Data Access Logs r2 On Bucket 1.55 KB 7 days
AI Gateway ai-gateway On Gateway 2 KB 7 days
Issues real-time-issues On Worker 2.64 KB 7 days
HTTP Requests http_requests On Account 1.56 KB 30 days
Firewall Events firewall_events On Account 1.36 KB 30 days
Access Requests access_requests On Account 446 B 30 days
Audit Logs audit_logs On Account 2.69 KB 30 days
Audit Logs v2 audit_logs_v2 On Account 1.73 KB 30 days
Browser Isolation User Actions biso_user_actions On Account Not published 30 days
CASB Findings casb_findings On Account 2.67 KB 30 days
DEX Application Tests dex_application_tests On Account 3.29 KB 30 days
DEX Device State Events dex_device_state_events On Account 1.98 KB 30 days
Device Posture Results device_posture_results On Account 730 B 30 days
DNS Firewall Logs dns_firewall_logs On Account 387 B 30 days
DNS Logs dns_logs On Account 199 B 30 days
Email Security Alerts email_security_alerts On Account 6.74 KB 30 days
Gateway DNS gateway_dns On Account 1.44 KB 30 days
Gateway HTTP gateway_http On Account 1.47 KB 30 days
Gateway Network gateway_network On Account 877 B 30 days
IPsec Logs ipsec_logs On Account 207 B 30 days
Magic BGP Logs magic_bgp_logs On Account Not published 30 days
Magic IDS Detections magic_ids_detections On Account 334 B 30 days
NEL Reports nel_reports On Account 204 B 30 days
Network Analytics network_analytics_logs On Account 1.31 KB 30 days
Page Shield Events page_shield_events On Account 443 B 30 days
Sinkhole HTTP Logs sinkhole_http_logs On Account 705 B 30 days
Spectrum Events spectrum_events On Account 685 B 30 days
WARP Toggle Changes warp_toggle_changes On Account 327 B 30 days
Zaraz Events zaraz_events On Account 7.30 KB 30 days
Zero Trust Network Session Logs zero_trust_network_sessions On Account 1.21 KB 30 days

Sampled analytics datasets

Logs also lists HTTP requests and firewall events from the GraphQL Analytics API. These datasets need no enablement and have no additional charge. The following sampled analytics datasets are available:

Dataset GraphQL dataset Availability Retention
HTTP requests httpRequestsAdaptive All plans At least 31 days
Firewall events firewallEventsAdaptive Pro, Business, and Enterprise At least 31 days

These datasets use adaptive sampling. Results can omit individual events, and counts can be estimates. Available fields, exact retention, and how far back charts reach depend on your plan. Refer to GraphQL Analytics API limits for details.

To query these datasets for a zone, you need the Zone Analytics Read permission for that zone. Account administrators can grant it on the Members page.

For unsampled HTTP requests and firewall events, turn them on in Log Explorer. They need the paid Log Explorer add-on. Refer to Pricing for the Log Explorer price.

Pricing

Beginning December 1, 2026, all Cloudflare logs and traces will use the same pricing model. Log Explorer datasets have a different price point of $1 per GB ingested and include 30-day retention. Queries, dashboards, alerts, and analytics do not incur additional charge.

Included in the new Observability pricing

The following logs and traces share account-level ingestion and storage allowances:

Logs

Use Logs to query structured events from supported Cloudflare products and services. Filter by time range and field values, then chart or inspect matching events.

You can use Logs to:

Logs showing Worker query controls, outcome and duration visualizations, and a table of structured events.

Choose a dataset

Open the dataset selector to search available datasets, including HTTP requests, security events, Workers, Containers, R2, AI Gateway, and Issues. For domain-scoped datasets, select one domain or all domains.

Available fields and retention periods vary by dataset, and some datasets must be turned on in their source product.

Dataset selector showing HTTP requests, Workers, Containers, R2, and Issues.

Narrow the results

Use the field browser to search field names or browse categories. To create a filter, select a field, operator, and value.

You can also enter a query directly, either in the filter query language or as SQL against the selected dataset. The built-in reference covers field queries, comparison operators, functions, Boolean logic, examples, and keyboard shortcuts. To inspect one request, filter on its Ray ID.

Select a preset time range, enter a relative range, or select calendar dates. Results show the returned row count and query duration.

Logs filter builder matching requests where Path equals /.env, with the generated query and filtered chart.

Visualize results

Create a visualization from a field, describe the chart you want in plain language, or configure one from scratch. Group results by one or more fields, or add, remove, and reorder custom series with separate labels, metrics, and filters. When Logs detects an anomaly in a series, select it to narrow the results to the affected time range and investigate.

Available chart types include:

Use automatic interval selection or select an interval from one minute to one day. Resize the visualization area, duplicate or remove a chart, and add the chart to a custom dashboard.

Logs visualizations showing Worker invocation outcomes, error outcomes, latency, and an empty chart ready to configure.

Log Explorer API

Configuration and Log searches are also available via a public API.

Authentication

Authentication with the API can be done via an API token or API key with an email. Refer to Create API token for further instructions.

For detailed information on permissions required for each feature, refer to the Permissions section.

Query data

Log Explorer includes a SQL API for submitting queries.

For example, to find an HTTP request with a specific Ray ID, use the following SQL query:

curl https://api.cloudflare.com/client/v4/zones/{zone_id}/logs/explorer/query/sql \
--header "Authorization: Bearer <API_TOKEN>" \
--url-query query="SELECT clientRequestScheme, clientRequestHost, clientRequestMethod, edgeResponseStatus, clientRequestUserAgent FROM http_requests WHERE RayID = '806c30a3cec56817' LIMIT 1"

This command returns the following HTTP request details:

{
	"result": [
		{
			"clientrequestscheme": "https",
			"clientrequesthost": "example.com",
			"clientrequestmethod": "GET",
			"clientrequestuseragent": "curl/7.88.1",
			"edgeresponsestatus": 200
		}
	],
	"success": true,
	"errors": [],
	"messages": []
}

As another example, you could find Cloudflare Access requests with selected columns from a specific timeframe by performing the following SQL query:

curl https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/explorer/query/sql \
--header "Authorization: Bearer <API_TOKEN>" \
--url-query query="SELECT CreatedAt, AppDomain, AppUUID, Action, Allowed, Country, RayID, Email, IPAddress, UserUID FROM access_requests WHERE Date >= '2025-02-06' AND Date <= '2025-02-06' AND CreatedAt >= '2025-02-06T12:28:39Z' AND CreatedAt <= '2025-02-06T12:58:39Z'"

This command returns the following request details:

{
	"result": [
		{
			"createdat": "2025-01-14T18:17:55Z",
			"appdomain": "example.com",
			"appuuid": "a66b4ab0-ccdf-4d60-a6d0-54a59a827d92",
			"action": "login",
			"allowed": true,
			"country": "us",
			"rayid": "90fbb07c0b316957",
			"email": "user@example.com",
			"ipaddress": "1.2.3.4",
			"useruid": "52859e81-711e-4de0-8b31-283336060e79"
		}
	],
	"success": true,
	"errors": [],
	"messages": []
}

Changelog

import { ProductChangelog } from "~/components";

{/* <!-- Actual content lives in /src/content/changelog/logs. Update the file there for new entries to appear here. */}

Example SQL queries

The following examples show practical SQL queries you can use with the http_requests dataset in Log Explorer. For the full list of supported SQL syntax, refer to SQL queries supported.

Adjust the date ranges in each example to match the time period you want to query.

Summarize CDN usage

Get a high-level summary of total requests and data transfer for a specific time period. Results include total bytes transferred and conversions to megabytes and gigabytes.

SELECT
  COUNT(*) AS total_requests,
  SUM(EdgeResponseBytes) AS total_data_transfer,
  SUM(EdgeResponseBytes) / (1024.0 * 1024.0 * 1024.0) AS total_data_transfer_gb,
  SUM(EdgeResponseBytes) / (1024.0 * 1024.0) AS total_data_transfer_mb
FROM
  http_requests
WHERE {{ timeFilter }}

Review distribution of security actions

Understand how security actions, such as blocks and challenges, are distributed across your traffic and identify the most common security responses applied to requests.

SELECT
  SecurityAction,
  COUNT(*) AS ActionCount
FROM http_requests
WHERE SecurityAction != 'unknown'
  AND SecurityAction IS NOT NULL
GROUP BY SecurityAction
ORDER BY ActionCount DESC

Find IPs that triggered challenges

Identify the top client IP addresses and request URIs that triggered managed, JavaScript, or interactive challenges to investigate potential bot activity or targeted attacks.

SELECT
  ClientIP,
  ClientRequestURI,
  SecurityActions,
  COUNT(*) AS Count
FROM http_requests
WHERE {{ timeFilter }}
  AND (
    ARRAY_CONTAINS(SecurityActions, 'challenge')
    OR ARRAY_CONTAINS(SecurityActions, 'managedChallenge')
    OR ARRAY_CONTAINS(SecurityActions, 'jsChallenge')
    OR ARRAY_CONTAINS(SecurityActions, 'challengeSolved')
  )
GROUP BY
  ClientIP,
  ClientRequestURI,
  SecurityActions
ORDER BY Count DESC
LIMIT 20

Find highest bandwidth consumers by URI

Identify which request URIs consume the most bandwidth to pinpoint large assets or endpoints that drive the most data transfer.

SELECT
  ClientRequestURI,
  SUM(EdgeResponseBytes) / (1024 * 1024) AS MegabytesTransferred
FROM http_requests
WHERE  {{ timeFilter }}
GROUP BY ClientRequestURI
ORDER BY MegabytesTransferred DESC
LIMIT 10

Analyze client round-trip time by country

Analyze client TCP round-trip time (RTT) across different countries to identify regions with high latency that might benefit from additional optimization.

SELECT
  ClientCountry,
  COUNT(*) AS requests,
  AVG(ClientTCPRttMs) AS avg_rtt,
  MIN(ClientTCPRttMs) AS min_rtt,
  MAX(ClientTCPRttMs) AS max_rtt
FROM http_requests
WHERE {{ timeFilter }}
GROUP BY ClientCountry
ORDER BY avg_rtt DESC
LIMIT 20

Summarize CDN traffic by cache status

Break down traffic by cache status and measure the average time to first byte (TTFB) for each status to evaluate cache effectiveness and identify opportunities to improve cache hit ratios.

SELECT
  CacheCacheStatus,
  COUNT(*) AS requests,
  SUM(EdgeResponseBytes) AS total_bytes,
  AVG(EdgeTimeToFirstByteMs) AS avg_ttfb
FROM http_requests
WHERE {{ timeFilter }}
GROUP BY CacheCacheStatus
ORDER BY requests DESC

Find slowest paths by time to first byte

Find request paths with the highest average time to first byte (TTFB), along with request counts and server error counts toidentify slow endpoints that may need optimization.

SELECT
  ClientRequestPath,
  AVG(EdgeTimeToFirstByteMs) AS avg_ttfb,
  COUNT(*) AS requests,
  SUM(CASE WHEN EdgeResponseStatus >= 500 THEN 1 ELSE 0 END) AS errors
FROM http_requests
WHERE {{ timeFilter }}
GROUP BY ClientRequestPath
ORDER BY avg_ttfb DESC
LIMIT 10

FAQ

import { DashButton } from "~/components";

These questions cover Log Explorer (Legacy).

Which fields (or columns) are available for querying?

All fields listed in Datasets for the supported datasets can be queried.

Why is the MatchedRules field empty for some requests?

MatchedRules is populated only by security and transformation rules (WAF, Rate Limiting, Transform Rules, Snippets). Cache rules do not populate this field. If you are investigating cache behavior, use the Cache* fields such as CacheCacheStatus instead.

Why does my query not complete or time out?

Queries perform best when their parameters focus on narrower ranges of time. You may experience query timeouts when your query would return a large quantity of data. Consider refining your query to improve performance.

Why do I not see any logs in my queries after enabling the dataset?

Ingestion starts from the moment you enable the dataset. Logs for events that occurred before you enabled the dataset are not available. Make sure that new events have been generated since enabling the dataset, and check again.

My query returned an error. How do I figure out what went wrong?

We are actively working on improving error codes. If you receive a generic error, check your SQL syntax (if you are using the custom SQL feature), and make sure you have included a date and a limit. If the query still fails it is likely timing out. Try refining your filters.

Where is the data stored?

The data is stored in Cloudflare R2. Each dataset is stored on a per-customer level, similar to Cloudflare D1, ensuring that your data is kept separate from that of other customers. In the future, this single-tenant storage model will provide you with the flexibility to create your own retention policies and decide in which regions you want to store your data.

Does Log Explorer support Customer Metadata Boundary?

Customer Metadata Boundary is currently not supported for Log Explorer.

Are there any constraints on the log volume that Log Explorer can support?

We are continually scaling the Log Explorer data platform. At present, Log Explorer supports log ingestion rates of up to 50,000 records per second. If your needs exceed this, contact your account team.

How is Log Explorer different from Logpush? Do I need both?

Log Explorer lets you search and analyze your Cloudflare logs directly in the dashboard or via API. Logpush, on the other hand, delivers raw logs to third-party SIEMs or storage systems. You generally do not need both, but some customers choose to use these datasets for quick investigation and Logpush for long-term storage or integration with other tools.

Is there a free version or trial of Log Explorer?

Log Explorer is available as a paid add-on for any Application Services or Zero Trust purchase. There is no free version at this time.

How is Log Explorer billed?

Billing is based on the volume of logs indexed and stored, measured in gigabytes (GB). Your charges scale with the amount of log data you choose to retain. Unlike query-based billing models (for example, BigQuery), charges are not based on how often you search or scan your data. Once logs are ingested and stored, you can query them without additional cost.

Are logs from attack traffic included in my Log Explorer usage?

Yes. In general, billing is based on the total volume of logs ingested and stored, including attack traffic. Since these logs are often critical for investigating security incidents, they are treated the same as all other log data.

However, logs generated from Layer 7 (L7) DDoS attack traffic are not ingested by default and therefore do not count toward your usage.

How does Log Explorer store data in R2, and why do I not see it in my own R2 bucket?

Log Explorer uses Cloudflare Logpush and R2 behind the scenes to stream and store logs. For technical and performance reasons, the data is stored in internal, customer-specific R2 buckets managed by Cloudflare. These buckets are single-tenant to keep your data isolated, but they are not visible in your account's R2 interface. You are not billed separately for this storage — it is included in your usage.

Are Custom Dashboards based on R2 Log Explorer data, or on GraphQL?

Custom Dashboards use GraphQL for standard analytics datasets.

Customers with the Log Explorer add-on can also select Log Explorer datasets to create charts from raw, unsampled log data. This is supported on all plans and account types, with no additional enablement required.

You cannot turn a saved or active query directly into a Custom Dashboard chart.

For more information, refer to Custom dashboards.

How can I track my Log Explorer usage?

Your monthly usage is displayed at the top of the Log Search and Manage Datasets dashboard sections.

Usage display in the dashboard

How do I turn off Log Explorer?

To turn off Log Explorer you must:

  1. Stop log ingestion to immediately stop incurring additional charges. To stop log ingestion, turn off any datasets that are on at both the account level and zone level.
  2. Cancel the Log Explorer subscription to stop renewal. Your subscription may remain active until the end of the current billing cycle.

1. Stop log ingestion

After performing the following steps, you will immediately stop incurring additional charges for Log Explorer.

Review and turn off account-level datasets

  1. In the Cloudflare dashboard, go to the account-level Manage datasets page.

  2. Turn off each dataset you no longer need using the toggle. To confirm each operation, select Stop ingesting logs.

Review and turn off zone-level datasets

  1. In the Cloudflare dashboard, go to the zone-level Manage datasets page.

  2. Turn off each dataset you no longer need using the toggle. To confirm each operation, select Stop ingesting logs.

  3. Repeat for all relevant zones.

2. Cancel the Log Explorer subscription

This operation will stop Log Explorer's renewal.

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

  2. In the Subscriptions tab, find the Log Explorer subscription and select Cancel.

Log Explorer (Legacy)

import { Description, Feature, RelatedProduct } from "~/components"

Store and explore your Cloudflare logs directly within the Cloudflare dashboard or API.

Log Explorer (Legacy) lets security teams and developers analyze, investigate, and monitor issues directly from the Cloudflare dashboard, without the expense and complexity of forwarding logs to third-party tools.

Log Explorer is labeled Legacy because it is being merged into Observability Logs. Your datasets, subscription, and API access continue to work.

Log Explorer provides access to Cloudflare logs with all the context available within the Cloudflare platform. You can monitor security and performance issues with custom dashboards or investigate and troubleshoot issues with log search. Benefits include:

Contract customers can choose to store their logs in Log Explorer for up to two years, at an additional cost of $0.10 per GB per month. Customers interested in this feature can contact their account team to have it added to their contract.

Permissions

Access to Log Explorer depends on how you connect. Account members need a member role, and API tokens need an API token permission. The token permissions are not member roles and do not appear in the role picker.

Feature Member role API token permission Description
Log Search Log Share Reader (Log Share and Administrator Read Only also work) Logs Read Query logs in the dashboard or via API.
Log Search (save query) Super Administrator or Administrator Logs Edit Save, edit, or delete log search queries.
Manage datasets Super Administrator or Administrator Logs Edit Add, enable, or disable datasets.
Custom dashboards Analytics Analytics Read Create and view custom dashboards.

The API lists Logs Edit as Logs Write. They are the same permission.

Grant roles and permissions at the account level to query account-level datasets. A role assigned to specific zones only covers that zone's datasets.

For zone-level datasets and saved queries, Log Share can also make changes.

Some datasets need an additional member role:

Authentication with the API can be done via an API token or API key with an email. Refer to Create API token for further instructions.

Features

Explore your Cloudflare logs from the [Logs](/observability/logs/) page under Observability in the Cloudflare dashboard, or via the [API](/observability/logs/log-explorer/api/). Design customized views for tracking application security, performance, and usage metrics. Choose which datasets to store in Log Explorer. Manage configuration and perform queries via the API. Forward Cloudflare logs to third-party tools for debugging, identifying configuration adjustments, and creating analytics dashboards. Visualize the metadata collected by our products in the Cloudflare dashboard.

Log Search

import { TabItem, Tabs, Render, DashButton } from "~/components";

Log Explorer (Legacy) lets you store and explore your Cloudflare logs directly within the Cloudflare dashboard or API, giving you visibility into your logs without the need to forward them to third-party services. Logs are stored on Cloudflare's global network using the R2 object storage platform and can be queried via the dashboard or SQL API.

:::note[Log Search is now part of Observability Logs] Log Explorer datasets are queried from the Logs page under Observability in the Cloudflare dashboard. The Log Explorer menu is no longer shown in the dashboard navigation. Your enabled datasets, saved queries, and SQL queries continue to work on the Logs page, and the previous Log Search page remains available at its direct URL. :::

When to use Log Explorer

Use Rules simulator, shown as Rule simulator in the dashboard, when you need to test what would happen with a simulated request:

The key difference is that Log Explorer shows actual traffic, while Cloudflare Trace shows simulated "what-if" scenarios. Both are separate from Cloudflare Traces, which records how real requests move through Cloudflare.

Use Log Explorer

You can filter and view your logs via the Cloudflare dashboard or the API.

  1. In the Cloudflare dashboard, go to Observability > Logs.

  2. Open the dataset selector and choose a Log Explorer dataset, such as HTTP requests. For zone-scoped datasets, select one domain or all domains.

  3. Select a preset or custom time range.

  4. Add filters by selecting a field, an operator, and a value. To write SQL instead, select Open SQL editor, enter a query against the selected dataset, and select Run query.

SQL queries are available for Log Explorer datasets only. For the filter query language, functions, and keyboard shortcuts, refer to the built-in reference on the Logs page or the Logs overview.

For example, to find an HTTP request with a specific Ray ID, open the SQL editor and enter the following SQL query:

SELECT
	clientRequestScheme,
	clientRequestHost,
	clientRequestMethod,
	edgeResponseStatus,
	clientRequestUserAgent
FROM http_requests
WHERE RayID = '806c30a3cec56817'
LIMIT 1

As another example, to find Cloudflare Access requests with selected columns from a specific timeframe you could perform the following SQL query:

SELECT
	CreatedAt,
	AppDomain,
	AppUUID,
	Action,
	Allowed,
	Country,
	RayID,
	Email,
	IPAddress,
	UserUID
FROM access_requests
WHERE Date >= '2025-02-06' AND Date <= '2025-02-06' AND CreatedAt >= '2025-02-06T12:28:39Z' AND CreatedAt <= '2025-02-06T12:58:39Z'

Headers and cookies

To query request headers, response headers, and cookies you must first enable logging for these fields using Custom fields. Configure the list of custom fields using the API or the dashboard; there is no need to modify the Logpush job itself.

The example below shows how to query HTTP requests by date, timestamp, client country, and a custom request header. Be sure to log the specific headers or cookies you plan to query in advance.

SELECT clientip, clientrequesthost, clientrequestmethod, edgeendtimestamp, edgestarttimestamp, rayid, clientcountry, requestheaders
FROM http_requests
WHERE Date >= '2025-07-17'
  AND Date <= '2025-07-17'
  AND edgeendtimestamp >= '2025-07-17T07:54:19Z'
  AND edgeendtimestamp <= '2025-07-18T07:54:19Z'
  AND clientcountry = 'us'
  AND requestheaders."x-test-header" like '%654AM%';

Save queries

After building your query, you can save it by selecting Save search. Provide a name and description to help identify it later. To view your saved searches, select Saved searches. Queries saved in the previous Log Search page appear as saved searches on the Logs page.

Integration with Security Analytics

You can also open Log Search directly from the Security Analytics dashboard. When doing so, the filters you applied in Security Analytics will automatically carry over to your query.

Optimize your queries

All Log Explorer datasets contain a special column called date, which helps to narrow down the amount of data that is scanned to respond to your query, resulting in faster query response times. The value of date must be in the form of YYYY-MM-DD. For example, to query logs that occurred on October 12, 2023, add the following to your WHERE clause: date = '2023-10-12'. The column supports the standard operators of <, >, and =.

  1. Log in to the Cloudflare dashboard and select your account.
  2. Go to Observability > Logs, select a Log Explorer dataset, and select Open SQL editor.
  3. Enter the following SQL query:
SELECT
	clientip,
	clientrequesthost,
	clientrequestmethod,
	clientrequesturi,
	edgeendtimestamp,
	edgeresponsestatus,
	originresponsestatus,
	edgestarttimestamp,
	rayid,
	clientcountry,
	clientrequestpath,
	date
FROM
	http_requests
WHERE
	date = '2023-10-12' LIMIT 500

Additional query optimization tips

Manage datasets

import { TabItem, Tabs, Render, DashButton, Steps } from "~/components";

You can enable, disable, or delete the Log Explorer datasets available to query in Logs.

:::note Canceling a Log Explorer subscription stops renewal, but it does not automatically stop log ingestion during the current billing cycle. To completely turn off Log Explorer, refer to How do I turn off Log Explorer?. :::

Supported datasets

Log Explorer currently supports the following datasets:

Zone level

Account level

Enable Log Explorer

To begin storing logs, enable the desired datasets through the dashboard or API.

Dashboard

  1. In the Cloudflare dashboard, open the Manage datasets page. From Observability > Logs, open the dataset selector and select Configure next to the Log Explorer datasets, or use the button below.

  2. Select Add dataset.

  3. Choose a dataset and, for zone-level datasets, a zone.

  4. Under Select fields, choose the fields to ingest.

  5. Under Filter logs, choose whether to ingest all events or only events that match a filter.

  6. Select Add.

:::note It may take a few minutes for the logs to become available for querying. :::

Configure fields and filters

Use Select fields to control which data points are stored. Fields are grouped by category, and each category shows its selected field count. Select a category to add or remove all fields in that group, or expand the category to select individual fields. Each field shows its data type.

Required fields remain selected and are marked Required. Fields that Cloudflare no longer recommends are marked Deprecated. Select Select all to include every available field, or Reset to default to restore the dataset defaults.

Use Filter logs to ingest All events or Only events matching a filter. A filter condition consists of a field, an operator, and a value. All conditions within a group must match. An event can match any filter group.

To change the fields or filter for an enabled dataset, open the Manage datasets page. Find the dataset, select Actions > Edit, update the configuration, and select Update.

API

Use the API to enable each dataset you want to store. It may take a few minutes after a log stream is enabled before you can view the logs.

The following curl command is an example for enabling the zone-level dataset http_requests, as well as the expected response when the command succeeds.

curl https://api.cloudflare.com/client/v4/zones/{zone_id}/logs/explorer/datasets \
--header "Authorization: Bearer <API_TOKEN>" \
--json '{
  "dataset": "http_requests"
}'

{
	"result": {
		"dataset": "http_requests",
		"object_type": "zone",
		"object_id": "<ZONE ID>",
		"created_at": "2025-06-03T14:33:16Z",
		"updated_at": "2025-06-03T14:33:16Z",
		"dataset_id": "01973635f7e273a1964a02f4d4502499",
		"enabled": true,
		"deletion_protection": true
	},
	"success": true,
	"errors": [],
	"messages": []
}

To enable an account-level dataset, replace zones/{zone_id} with accounts/{account_id} in the curl command. For example:

curl https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/explorer/datasets \
--header "Authorization: Bearer <API_TOKEN>" \
--json '{
  "dataset": "access_requests"
}'

Delete a dataset

Deleting a dataset permanently removes the dataset and its stored data. Deletion runs asynchronously. You cannot recreate the same dataset for the account or zone while deletion is in progress.

:::caution Dataset deletion is irreversible. Deleted data cannot be recovered. :::

  1. In the Cloudflare dashboard, open the Manage datasets page.

  2. Find the dataset and select Actions > Delete.

  3. If deletion protection is enabled, disable it in the confirmation dialog.

  4. Enter the dataset name and select Delete.

  1. Set deletion_protection to false with the Update an account or zone dataset method.
  2. Delete the dataset with the Delete an account or zone dataset method.

Pricing and managing usage

Log Explorer (Legacy) is billed on the volume of logs ingested and stored, measured in gigabytes (GB). Your charges scale with the amount of log data you choose to retain.

Unlike query-based billing models, charges are not based on how often you search or scan your data. Once logs are ingested and stored, you can query them without additional cost.

Availability

Log Explorer is available as a paid add-on for any Application Services or Zero Trust purchase. There is no free version or trial available at this time.

Billable usage

Billing is strictly consumption-based, calculated by the GBs ingested and stored.

Attack traffic

Because these datasets are used for forensics, attack traffic is considered valuable data for analysis and is included in your billable usage.

:::note Logs generated from Layer 7 (L7) DDoS attack traffic are not ingested by default and do not count toward your usage. :::

Estimate usage

To estimate your usage, review your request volumes in Analytics for specific Cloudflare log datasets.

Record size by dataset

The following table provides average and maximum record sizes for each dataset to help you estimate potential storage needs:

Dataset Average Record Size Maximum Record Size
audit_logs 2.69 kB 172 kB
email_security_alerts 6.74 kB 74.9 kB
firewall_events 1.36 kB 47.2 kB
audit_logs_v2 1.73 kB 28.5 kB
zaraz_events 7.30 kB 11.7 kB
http_requests 1.56 kB 9.76 kB
gateway_dns 1.44 kB 6.23 kB
dex_application_tests 3.29 kB 5.67 kB
casb_findings 2.67 kB 3.80 kB
gateway_http 1.47 kB 2.60 kB
dex_device_state_events 1.98 kB 2.57 kB
page_shield_events 443 B 2.02 kB
network_analytics_logs 1.31 kB 1.87 kB
zero_trust_network_sessions 1.21 kB 1.52 kB
gateway_network 877 B 1.17 kB
device_posture_results 730 B 944 B
spectrum_events 685 B 925 B
sinkhole_http_logs 705 B 705 B
access_requests 446 B 541 B
dns_firewall_logs 387 B 469 B
dns_logs 199 B 409 B
magic_ids_detections 334 B 349 B
warp_toggle_changes 327 B 335 B
ipsec_logs 207 B 260 B
nel_reports 204 B 224 B

Monitor usage

Cloudflare provides three primary ways to track your consumption and maintain financial oversight:

Configure a usage alert

  1. Log in to the Cloudflare dashboard and select Manage account.
  2. Go to Notifications > Add.
  3. Select Usage-based Billing.
  4. Define your threshold and the notification destination (email, PagerDuty, or webhooks).

Deactivate Log Explorer

To stop using Log Explorer and end associated charges, you must complete both of the following steps:

1. Stop log ingestion

Disabling datasets stops additional ingestion charges immediately.

  1. Go to the Manage datasets page at the account level.
  2. Use the toggle to turn off each dataset you no longer need.
  3. Select Stop ingesting logs to confirm.

2. Cancel the subscription

This prevents the subscription from renewing at the next billing cycle.

  1. Go to the Billing page.
  2. In the Subscriptions tab, find the Log Explorer subscription and select Cancel.

SQL queries supported

import { Details } from "~/components"

This page outlines the SQL features supported by Log Explorer, including common aggregation functions, expressions, and query clauses.

The following diagram illustrates the general shape of a valid query on these datasets. It shows how standard SQL clauses — such as SELECT, WHERE, GROUP BY, and ORDER BY — can be composed to form supported queries.

Supported SQL grammar

Examples of queries include:

:::note

SQL Clauses in detail

The following SQL clauses define the structure and logic of queries in Log Explorer:

The sections that follow break down the remaining components shown in the diagram — such as aggregation functions, string and numeric expressions, and supported operators — in more detail.

Functions

Queries support a range of SQL functions to transform, evaluate, or summarize data. These include scalar and aggregation functions.

Scalar functions

These help manipulate or evaluate values (often strings):

Aggregation functions

Used to perform calculations on sets of rows:

The diagram below represents the grammar for SQL expressions including scalar and aggregate functions.

Scalar and aggregate functions

Expressions

Conditions or logic used in queries:

The diagram below represents the grammar for SQL expressions, detailing the various forms an expression can take, including columns, literals, functions, operators, and aliases.

SQL expressions

The diagram below defines the grammar for unary operators, which operate on a single operand (for example, negation or logical NOT):

Grammar for unary operators

Binary Operators

Used for arithmetic, comparison, logical operations:

Pricing

Beginning December 1, 2026, all Cloudflare logs and traces will use the same pricing model. Log Explorer datasets have a different price point of $1 per GB ingested and include 30-day retention. Queries, dashboards, alerts, and analytics do not incur additional charge.

Refer to Datasets to review the price point and retention for each dataset.

Included in the new Observability pricing

The following logs and traces share account-level ingestion and storage allowances:

Plans

Plan Included ingestion Included storage Additional ingestion Additional storage
Free 0.5 GB per day Seven-day retention included Not available Not separately metered
Paid 50 GB per billing cycle 10 GB-month per billing cycle $0.25 per GB $0.10 per GB-month

Enterprise accounts move to this pricing when their contract renews. Until then, existing contract terms apply.

Paid usage continues automatically after an allowance is exhausted. Ingestion and storage are separate meters, so unused ingestion allowance cannot be applied to storage or the reverse. Allowances do not roll over between billing cycles.

You will be able to view your current ingestion and storage usage, remaining allowances, and estimated charges in Billable Usage.

On Free, Cloudflare stops ingesting new data when the account reaches its daily limit. Ingestion resumes when the allowance resets at 00:00 UTC. Stored data remains queryable for its seven-day retention period.

How usage is measured

Ingestion

Ingestion includes the event body, the default enriched attributes, and custom attributes. Ingestion is pre-compression and does not include dropped events. Sampling data before storage reduces both ingestion and storage usage.

Storage

Storage is measured in GB-month using the maximum amount of queryable data stored each day:

GB-month = sum of each day's maximum queryable GB / 30

For example, 1 GB that remains queryable for 30 days contributes 1 GB-month. Data stops contributing to storage usage when it is no longer queryable.

Example

Suppose a Paid account uses 75 GB of ingestion and 20 GB-month of storage during one billing cycle:

Usage Calculation Additional charge
Ingestion (75 GB - 50 GB included) x $0.25 $6.25
Storage (20 GB-month - 10 GB-month included) x $0.10 $1.00
Total $6.25 + $1.00 $7.25

Longer retention

Logs and traces in the shared allowance have a default seven-day retention. Log Explorer datasets include 30-day retention. Cloudflare plans to add configurable 30, 90, and 365-day retention periods in the future.

Existing customers

Existing Workers Observability customers on Free, Pro, and Business plans automatically move to this pricing on December 1, 2026. Ingestion charges apply only to data received on or after that date. Enterprise accounts move at contract renewal.

For Paid accounts, data retained on December 1 begins contributing to storage usage from that date. Usage before December 1 is not charged retroactively.

Log Explorer (Legacy)

Log Explorer datasets preserve complete event fidelity and use a different ingestion price point. Their usage does not consume the pooled allowances in Plans. For usage estimates, monitoring, and deactivation, refer to Pricing and managing usage.

Ingestion Retention Queries
$1 per GB ingested 30 days No additional charge

Configuration

Configure Cloudflare Traces separately for each domain. Choose how many requests to trace, where to save or send traces, and whether to connect them to traces from other systems.

Trace settings for sampling, persistence, export destinations, trace rules, and trace context propagation.

API access

To manage trace rules and settings via the API, create an API token with the Zone Observability permission scoped to the relevant zone:

Refer to the API reference for full endpoint documentation.

Head sampling

Default sample rate (%) sets how many requests Cloudflare traces. For example, a rate of 10% traces about 10 out of every 100 requests. Trace rules can use a different rate for requests that match a rule.

Cloudflare makes the sampling decision when the request arrives. Once a request is selected for tracing, Cloudflare captures the full request path. There is no overhead with enabling tracing.

:::note[Free plan daily limit] Free accounts have a daily ingestion limit. When this limit is reached, Cloudflare stops ingesting new traces for the remainder of that day. Refer to Cloudflare Observability pricing for limit details. :::

Trace rules

Trace rules override the default sample rate for matching requests. Cloudflare uses the first matching rule, so rule order matters.

Choose Custom filter expression to match selected requests, or choose All incoming requests to apply the rule to every request. Build a custom filter from fields, operators, and values, or select Edit expression to write it with the Cloudflare Rules language.

Set Sample rate (%) to the percentage of matching requests you want to trace. Select Save as Draft to keep the rule inactive, or select Deploy to start using it.

A trace rule that samples all incoming requests with a URL path starting with /api/v1.

Persist traces

Turn on Persist to Cloudflare to save traces in Cloudflare and view them in the dashboard.

:::note[Pricing] Beginning December 1, 2026, persisted traces contribute to Cloudflare Observability ingestion and storage usage. Refer to Cloudflare Observability pricing. :::

Export traces

Use Export destinations to send traces to configured account-level OpenTelemetry destinations. To create a destination or configure a provider, refer to OpenTelemetry export.

You can save and export the same traces. If you only want traces in an external tool, turn off Persist to Cloudflare.

Propagate trace context

Trace context carries identifiers that connect spans from different systems into one trace. Cloudflare uses W3C Trace Context to connect its spans to services before or after Cloudflare in the request path. You can configure incoming and outgoing propagation separately.

Incoming trace context

Use Incoming trace context to choose whether Cloudflare accepts trace context included with an incoming request. The default setting is Reject, which ignores the incoming context so Cloudflare does not join the caller's trace.

:::caution Cloudflare does not verify that incoming trace context came from a trusted caller. If you accept it, treat the joined trace as untrusted. :::

Forward context to your origin

Turn on Forward to origin to include trace context in requests that Cloudflare sends to your origin. An instrumented origin can use this context to add its spans to the same trace. Forwarding context does not instrument the origin or create origin spans by itself.

To view Cloudflare and origin spans in one trace in a third-party observability tool, send both sets of spans to the same OpenTelemetry destination.

Traces

Cloudflare Traces show how production requests move through Cloudflare and record traces from actual traffic on your domain. Each trace contains spans for supported steps in the request path, such as Rules, request routing, Cache, Workers, and origin connections. A span records how long an operation took, its outcome, and related attributes, which helps you see where a request slowed down or failed.

A Cloudflare trace showing request processing spans, Worker and origin operations, timing, and details for a selected span.

Use Cloudflare Traces to answer questions such as:

Enable tracing

Enable tracing separately for each domain in your account. To manage sampling, context, export destinations, and trace rules, refer to Configuration.

Inspect a trace

Use Add filter or enter a query to search across traces for the selected time range. To find the trace for one request, filter on its Ray ID.

Open a trace to see the full request path as a hierarchy of spans. Each row represents one operation, and its bar shows when the operation ran and how long it took. Expand a span to inspect its child operations, or search for a span by name.

Select a span to open its details. The detail panel shows the span status, service, trigger, span and trace IDs, duration compared to similar spans, and recorded attributes. You can search or copy the attributes while investigating the operation.

:::note[Rules simulator] Rules simulator simulates how Cloudflare configurations would handle a request. It does not show actual production traffic. :::

Frequently asked questions

Does tracing add latency to my requests

No. Tracing has no measurable overhead on request processing. Requests that are not sampled skip tracing entirely.

Why is there a gap in my trace

A Worker in the request path may not have Workers tracing enabled. Enable it using observability.traces.enabled = true in your Wrangler configuration.

Why is there no outbound connection span

If the response was served from cache, Cloudflare did not contact your origin. Check the cloudflare.cache.status attribute on the cache span to confirm it was a HIT rather than an origin connection.

How do I capture the trace for a specific request

Filter by Ray ID in the dashboard with cloudflare.ray_id = "<ray>". To guarantee a particular request is captured regardless of the default sample rate, create a trace rule that matches a custom debug header and sets the sample rate to 100%.

Can I sample only slow requests or errors

Not yet. Sampling is head-based — the decision happens when a request arrives, before the outcome is known. Tail-based sampling is not currently supported.

Are request header values captured in spans

Header names and the operations performed on them are captured. Header values are not captured. URLs and query strings are captured.

Are span names a stable interface

No. Span names and structure may change as the product evolves. Do not build hard dependencies on the exact shape of Cloudflare-emitted spans.

Spans

A span represents one operation within a trace. Each span records when an operation started and how long it took. Related spans form a hierarchy that shows how a request moved through Cloudflare.

The spans in a trace depend on the products and request path involved. A span appears only when the corresponding operation runs.

Span reference

Span What it covers What its duration measures
cloudflare_request Cloudflare's processing of an HTTP request. This is the root span for platform-level request processing. Starts after tracing configuration and sampling are resolved. Includes the request processing, upstream, response delivery, and post-processing, but excludes processing before tracing is activated.
response Response processing and delivery to the client. Starts after an upstream or internally generated response becomes available. This includes the time spent to fully stream the response back to the client.
workers_routing The decision to match, skip, or reject a Workers route or custom domain. A skipped means a skip or disabled route matched. Requests that are not eligible for Workers routing do not emit this span. Includes the time to evaluate the routes/custom domains that might match the request. Does not include the time executing the Worker.
page_rules One evaluation of a configured Page Rules set. Includes the time to evaluate the Page Rules. It does not include applying those actions to the request.
cache Getting a response from Cloudflare's cache, fetching or revalidating it when needed. On a cache hit, includes reading and transferring the cached response. If Cloudflare needs to fetch or revalidate the response, that time is included too, including waiting for another request already filling the cache. Includes the full response body, not just the cache lookup.
dynamic Fetching and returning an uncached response. Includes establishing a connection when needed, sending the request and its body, waiting for the response, and transferring the full response body. It is not just the time your origin spends processing the request.
upstream Fetching a response from another Cloudflare location using Tiered Cache. Includes establishing a connection when needed, sending the request, waiting for the other location to produce a response, and receiving its full response body. If that location needs to fetch from your origin, that wait is included. It is not just the network travel time between locations.

Ruleset phase spans

Ruleset phase spans measure rule execution and application of the phase output. They start after eligibility checks and request-body preparation, and end after Cloudflare applies the resulting actions. A skipped phase does not emit a span.

Span Ruleset phase covered
http_request_dynamic_redirect Dynamic Redirect Rules
http_request_transform Early request Transform Rules
http_config_settings Configuration Rules
http_request_origin Origin Rules
http_request_firewall_custom Custom rules
http_request_firewall_managed Managed rules
http_request_redirect Request redirect rules
http_request_late_transform_managed Managed late request transforms
http_request_late_transform Late request transforms
http_request_cache_settings Cache Rules
http_request_snippets Snippets rules
http_custom_errors Custom Error Rules
http_response_headers_transform_managed Managed response header transforms
http_response_headers_transform Response Header Transform Rules
http_response_compression Compression Rules
http_response_firewall_managed Managed response firewall processing

Workers runtime spans

Cloudflare Traces include spans for supported Workers runtime operations, including handler invocations, fetch calls, and binding operations.

Refer to Workers spans and attributes for the complete runtime reference. You can also create custom spans for application-specific operations.

:::note Workers tracing needs to be enabled to see Workers spans in a Cloudflare Trace. :::

Features without spans

Some Cloudflare features do not yet have dedicated spans. Requests processed by these features still appear in traces, but without span-level detail for that processing.