---
title: Core platform Changelog
image: https://developers.cloudflare.com/cf-twitter-card.png
---

[Skip to content](#%5Ftop) 

# Changelog

New updates and improvements at Cloudflare.

[ Subscribe to RSS ](https://developers.cloudflare.com/changelog/rss/index.xml) [ View RSS feeds ](https://developers.cloudflare.com/fundamentals/new-features/available-rss-feeds/) 

Core platform

![hero image](https://developers.cloudflare.com/_astro/hero.CVYJHPAd_26AMqX.svg) 

Apr 02, 2026
1. ### [BigQuery as Logpush destination](https://developers.cloudflare.com/changelog/post/2026-04-02-bigquery-destination/)  
[ Logs ](https://developers.cloudflare.com/logs/)  
Cloudflare Logpush now supports **BigQuery** as a native destination.  
Logs from Cloudflare can be sent to [Google Cloud BigQuery ↗](https://cloud.google.com/bigquery) via [Logpush](https://developers.cloudflare.com/logs/logpush/). The destination can be configured through the Logpush UI in the Cloudflare dashboard or by using the [Logpush API](https://developers.cloudflare.com/api/resources/logpush/subresources/jobs/).  
For more information, refer to the [Destination Configuration](https://developers.cloudflare.com/logs/logpush/logpush-job/enable-destinations/bigquery/) documentation.

Apr 01, 2026
1. ### [New QUIC RTT and delivery rate fields](https://developers.cloudflare.com/changelog/post/2026-04-01-l4-transport-telemetry-fields/)  
[ Rules ](https://developers.cloudflare.com/rules/)  
Two new fields are now available in rule expressions that surface Layer 4 transport telemetry from the client connection. Together with the existing [cf.timings.client\_tcp\_rtt\_msec](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/) field, these fields give you a complete picture of connection quality for both TCP and QUIC traffic — enabling transport-aware rules without requiring any client-side changes.  
Previously, QUIC RTT and delivery rate data was only available via the `Server-Timing: cfL4` response header. These new fields make the same data available directly in rule expressions, so you can use them in Transform Rules, WAF Custom Rules, and other phases that support dynamic fields.  
#### New fields  
| Field                              | Type    | Description                                                                                                                                                             |  
| ---------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |  
| cf.timings.client\_quic\_rtt\_msec | Integer | The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only populated for QUIC (HTTP/3) connections. Returns 0 for TCP connections. |  
| cf.edge.l4.delivery\_rate          | Integer | The most recent data delivery rate estimate for the client connection, in bytes per second. Returns 0 when L4 statistics are not available for the request.             |  
#### Example: Route slow connections to a lightweight origin  
Use a request header transform rule to tag requests from high-latency connections, so your origin can serve a lighter page variant:  
**Rule expression:**  
```  
cf.timings.client_tcp_rtt_msec > 200 or cf.timings.client_quic_rtt_msec > 200  
```  
**Header modifications:**  
| Operation | Header name    | Value |  
| --------- | -------------- | ----- |  
| Set       | X-High-Latency | true  |  
#### Example: Match low-bandwidth connections  
```  
cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000  
```  
For more information, refer to [Request Header Transform Rules](https://developers.cloudflare.com/rules/transform/request-header-modification/) and the [fields reference](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/).

Mar 25, 2026
1. ### [Logpush — More granular timestamps](https://developers.cloudflare.com/changelog/post/2026-03-25-logpush-granular-timestamps/)  
[ Logpush ](https://developers.cloudflare.com/logs/logpush/)[ Logs ](https://developers.cloudflare.com/logs/)  
Logpush now supports higher-precision timestamp formats for log output. You can configure jobs to output timestamps at millisecond or nanosecond precision. This is available in both the Logpush UI in the Cloudflare dashboard and the [Logpush API](https://developers.cloudflare.com/api/resources/logpush/subresources/jobs/).  
To use the new formats, set `timestamp_format` in your Logpush job's `output_options`:  
   * `rfc3339ms` — `2024-02-17T23:52:01.123Z`  
   * `rfc3339ns` — `2024-02-17T23:52:01.123456789Z`  
Default timestamp formats apply unless explicitly set. The dashboard defaults to `rfc3339` and the API defaults to `unixnano`.  
For more information, refer to the [Log output options](https://developers.cloudflare.com/logs/logpush/logpush-job/log-output-options/) documentation.

Mar 25, 2026
1. ### [New mTLS certificate fields for Transform Rules](https://developers.cloudflare.com/changelog/post/2026-03-25-rfc9440-mtls-fields/)  
[ Rules ](https://developers.cloudflare.com/rules/)  
Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in [RFC 9440 ↗](https://www.rfc-editor.org/rfc/rfc9440) format. Previously, forwarding client certificate information to your origin required custom parsing of PEM-encoded fields or non-standard HTTP header formats. These new fields produce output in the standardized `Client-Cert` and `Client-Cert-Chain` header format defined by RFC 9440, so your origin can consume them directly without any additional decoding logic.  
Each certificate is DER-encoded, Base64-encoded, and wrapped in colons. For example, `:MIIDsT...Vw==:`. A chain of intermediates is expressed as a comma-separated list of such values.  
#### New fields  
| Field                                                 | Type    | Description                                                                                                                                                      |  
| ----------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |  
| cf.tls\_client\_auth.cert\_rfc9440                    | String  | The client leaf certificate in RFC 9440 format. Empty if no client certificate was presented.                                                                    |  
| cf.tls\_client\_auth.cert\_rfc9440\_too\_large        | Boolean | true if the leaf certificate exceeded 10 KB and was omitted. In practice this will almost always be false.                                                       |  
| cf.tls\_client\_auth.cert\_chain\_rfc9440             | String  | The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediate certificates were sent or if the chain exceeded 16 KB. |  
| cf.tls\_client\_auth.cert\_chain\_rfc9440\_too\_large | Boolean | true if the intermediate chain exceeded 16 KB and was omitted.                                                                                                   |  
The chain encoding follows the same ordering as the TLS handshake: the certificate closest to the leaf appears first, working up toward the trust anchor. The root certificate is not included.  
#### Example: Forwarding client certificate headers to your origin server  
Add a request header transform rule to set the `Client-Cert` and `Client-Cert-Chain` headers on requests forwarded to your origin server. For example, to forward headers for verified, non-revoked certificates:  
**Rule expression:**  
```  
cf.tls_client_auth.cert_verified and not cf.tls_client_auth.cert_revoked  
```  
**Header modifications:**  
| Operation | Header name       | Value                                     |  
| --------- | ----------------- | ----------------------------------------- |  
| Set       | Client-Cert       | cf.tls\_client\_auth.cert\_rfc9440        |  
| Set       | Client-Cert-Chain | cf.tls\_client\_auth.cert\_chain\_rfc9440 |  
To get the most out of these fields, upload your client CA certificate to Cloudflare so that Cloudflare validates the client certificate at the edge and populates `cf.tls_client_auth.cert_verified` and `cf.tls_client_auth.cert_revoked`.  
Prevent header injection  
You should ensure that `Client-Cert` and `Client-Cert-Chain` headers received by your origin server can only originate from this transform rule — any client could send these headers directly.  
   * **If you use WAF custom rules to block requests with invalid mTLS connections:** The transform rule is sufficient. For all requests that reach your origin server, the rule will overwrite any existing `Client-Cert` and `Client-Cert-Chain` headers.  
   * **If you do not enforce mTLS at the WAF:** Add another transform rule that removes any incoming `Client-Cert` and `Client-Cert-Chain` headers from all requests (use expression `true`), ordered before the rule above. This ensures your origin server cannot receive client-supplied values for these HTTP headers.  
For more information, refer to [Mutual TLS authentication](https://developers.cloudflare.com/cloudflare-one/access-controls/service-credentials/mutual-tls-authentication/), [Request Header Transform Rules](https://developers.cloudflare.com/rules/transform/request-header-modification/), and the [fields reference](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/).

Mar 24, 2026
1. ### [Advanced WAF customization for AI Crawl Control blocks](https://developers.cloudflare.com/changelog/post/2026-03-24-waf-rule-preservation/)  
[ AI Crawl Control ](https://developers.cloudflare.com/ai-crawl-control/)  
AI Crawl Control now supports extending the underlying WAF rule with custom modifications. Any changes you make directly in the WAF custom rules editor — such as adding path-based exceptions, extra user agents, or additional expression clauses — are preserved when you update crawler actions in AI Crawl Control.  
If the WAF rule expression has been modified in a way AI Crawl Control cannot parse, a warning banner appears on the **Crawlers** page with a link to view the rule directly in WAF.  
For more information, refer to [WAF rule management](https://developers.cloudflare.com/ai-crawl-control/features/manage-ai-crawlers/#waf-rule-management).

Mar 20, 2026
1. ### [Stream logs from multiple replicas of Cloudflare Tunnel simultaneously](https://developers.cloudflare.com/changelog/post/2026-03-20-tunnel-replica-overview-and-multi-log-streaming/)  
[ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Cloudflare Tunnel for SASE ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/)  
In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all [replicas](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/) of that tunnel and supports streaming logs from multiple replicas at once.  
![View replicas and stream logs from multiple connectors](https://developers.cloudflare.com/_astro/tunnel-multiconn.DEOEaLlu_ZDxArh.webp)  
Previously, you could only stream logs from one replica at a time. With this update:  
   * **Replicas on the tunnel overview** — All active replicas for the selected tunnel now appear on that tunnel's overview page under **Connectors**. Select any replica to stream its logs.  
   * **Multi-connector log streaming** — Stream logs from multiple replicas simultaneously, making it easier to correlate events across your infrastructure during debugging or incident response. To try it out, log in to [Cloudflare One ↗](https://one.dash.cloudflare.com/) and go to **Networks** \> **Connectors** \> **Cloudflare Tunnels**. Select **View logs** next to the tunnel you want to monitor.  
For more information, refer to [Tunnel log streams](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) and [Deploy replicas](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/deploy-replicas/).

Mar 19, 2026
1. ### [Service Key authentication deprecated](https://developers.cloudflare.com/changelog/post/2026-03-19-service-key-authentication-deprecated/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Service Key authentication for the Cloudflare API is deprecated. Service Keys will stop working on September 30, 2026.  
[API Tokens](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) replace Service Keys with fine-grained permissions, expiration, and revocation.  
#### What you need to do  
Replace any use of the `X-Auth-User-Service-Key` header with an [API Token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) scoped to the permissions your integration requires.  
If you use `cloudflared`, update to a version from November 2022 or later. These versions already use API Tokens.  
If you use [origin-ca-issuer ↗](https://github.com/cloudflare/origin-ca-issuer), update to a version that supports API Token authentication.  
For more information, refer to [API deprecations](https://developers.cloudflare.com/fundamentals/api/reference/deprecations/).

Mar 19, 2026
1. ### [Manage Cloudflare Tunnels with Wrangler](https://developers.cloudflare.com/changelog/post/2026-03-19-wrangler-tunnel-commands/)  
[ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Workers ](https://developers.cloudflare.com/workers/)  
You can now manage [Cloudflare Tunnels](https://developers.cloudflare.com/tunnel/) directly from [Wrangler](https://developers.cloudflare.com/workers/wrangler/), the CLI for the Cloudflare Developer Platform. The new [wrangler tunnel](https://developers.cloudflare.com/workers/wrangler/commands/tunnel/) commands let you create, run, and manage tunnels without leaving your terminal.  
![Wrangler tunnel commands demo](https://developers.cloudflare.com/_astro/wrangler-tunnel.DOqrtGGg_7EDX0.webp)  
Available commands:  
   * `wrangler tunnel create` — Create a new remotely managed tunnel.  
   * `wrangler tunnel list` — List all tunnels in your account.  
   * `wrangler tunnel info` — Display details about a specific tunnel.  
   * `wrangler tunnel delete` — Delete a tunnel.  
   * `wrangler tunnel run` — Run a tunnel using the cloudflared daemon.  
   * `wrangler tunnel quick-start` — Start a free, temporary tunnel without an account using [Quick Tunnels](https://developers.cloudflare.com/tunnel/setup/#quick-tunnels-development).  
Wrangler handles downloading and managing the [cloudflared](https://developers.cloudflare.com/tunnel/downloads/) binary automatically. On first use, you will be prompted to download `cloudflared` to a local cache directory.  
These commands are currently experimental and may change without notice.  
To get started, refer to the [Wrangler tunnel commands documentation](https://developers.cloudflare.com/workers/wrangler/commands/tunnel/).

Mar 18, 2026
1. ### [SCIM provisioning for Authentik is now Generally Available](https://developers.cloudflare.com/changelog/post/2026-03-17-scim-authentik-support/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Cloudflare dashboard SCIM provisioning now supports [Authentik ↗](https://goauthentik.io/) as an identity provider, joining Okta and Microsoft Entra ID as explicitly supported providers.  
Customers can now sync users and group information from Authentik to Cloudflare, apply Permission Policies to those groups, and manage the lifecycle of users & groups directly from your Authentik Identity Provider.  
Note  
SCIM provisioning for the Cloudflare dashboard is available to Enterprise customers. You must be a Super Administrator to complete the initial setup.  
For more information:  
   * [SCIM provisioning overview](https://developers.cloudflare.com/fundamentals/account/account-security/scim-setup/)  
   * [Provision with Authentik](https://developers.cloudflare.com/fundamentals/account/account-security/scim-setup/authentik/)

Mar 18, 2026
1. ### [SCIM audit logging Support](https://developers.cloudflare.com/changelog/post/2026-03-18-scim-audit-logging/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Cloudflare dashboard SCIM provisioning operations are now captured in [Audit Logs v2](https://developers.cloudflare.com/fundamentals/account/account-security/audit-logs/), giving you visibility into user and group changes made by your identity provider.  
![SCIM audit logging](https://developers.cloudflare.com/_astro/2026-03-18-scim-audit-logging.DPKMiE8X_ZojL4c.webp)  
**Logged actions:**  
| Action Type       | Description                             |  
| ----------------- | --------------------------------------- |  
| Create SCIM User  | User provisioned from IdP               |  
| Replace SCIM User | User fully replaced (PUT)               |  
| Update SCIM User  | User attributes modified (PATCH)        |  
| Delete SCIM User  | Member deprovisioned                    |  
| Create SCIM Group | Group provisioned from IdP              |  
| Update SCIM Group | Group membership or attributes modified |  
| Delete SCIM Group | Group deprovisioned                     |  
For more details, refer to the [Audit Logs v2 documentation](https://developers.cloudflare.com/fundamentals/account/account-security/audit-logs/).

Mar 18, 2026
1. ### [Worker execution timing field now available in Rules](https://developers.cloudflare.com/changelog/post/2026-03-18-worker-timing-field/)  
[ Rules ](https://developers.cloudflare.com/rules/)  
The `cf.timings.worker_msec` field is now available in the Ruleset Engine. This field reports the wall-clock time that a Cloudflare Worker spent handling a request, measured in milliseconds.  
You can use this field to identify slow Worker executions, detect performance regressions, or build rules that respond differently based on Worker processing time, such as logging requests that exceed a latency threshold.  
#### Field details  
| Field                   | Type    | Description                                                                                       |  
| ----------------------- | ------- | ------------------------------------------------------------------------------------------------- |  
| cf.timings.worker\_msec | Integer | The time spent executing a Cloudflare Worker in milliseconds. Returns 0 if no Worker was invoked. |  
Example filter expression:  
```  
cf.timings.worker_msec > 500  
```  
For more information, refer to the [Fields reference](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/cf.timings.worker%5Fmsec/).

Mar 12, 2026
1. ### [Retry-After HTTP header for retryable 1xxx errors](https://developers.cloudflare.com/changelog/post/2026-03-12-retry-after-header-for-1xxx-errors/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Cloudflare-generated 1xxx error responses now include a standard `Retry-After` HTTP header when the error is retryable. Agents and HTTP clients can read the recommended wait time from response headers alone — no body parsing required.  
#### Changes  
Seven retryable error codes now emit `Retry-After`:  
| Error code | Retry-After (seconds) | Error name                  |  
| ---------- | --------------------- | --------------------------- |  
| 1004       | 120                   | DNS resolution error        |  
| 1005       | 120                   | Banned zone                 |  
| 1015       | 30                    | Rate limited                |  
| 1033       | 120                   | Argo Tunnel error           |  
| 1038       | 60                    | HTTP headers limit exceeded |  
| 1200       | 60                    | Cache connection limit      |  
| 1205       | 5                     | Too many redirects          |  
The header value matches the existing `retry_after` body field in JSON and Markdown responses.  
If a WAF rate limiting rule has already set a dynamic `Retry-After` value on the response, that value takes precedence.  
#### Availability  
Available for all zones on all plans.  
#### Verify  
Check for the header on any retryable error:  
Terminal window  
```  
curl -s --compressed -D - -o /dev/null -H "Accept: application/json" -A "TestAgent/1.0" -H "Accept-Encoding: gzip, deflate" "<YOUR_DOMAIN>/cdn-cgi/error/1015" | grep -i retry-after  
```  
References:  
   * [RFC 9110 section 10.2.3 - Retry-After ↗](https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3)  
   * [Cloudflare 1xxx error documentation](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/)

Mar 11, 2026
1. ### [JSON responses and RFC 9457 support for Cloudflare 1xxx errors](https://developers.cloudflare.com/changelog/post/2026-03-11-json-rfc9457-responses-for-1xxx-errors/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Cloudflare-generated 1xxx errors now return structured JSON when clients send `Accept: application/json` or `Accept: application/problem+json`. JSON responses follow [RFC 9457 (Problem Details for HTTP APIs) ↗](https://www.rfc-editor.org/rfc/rfc9457), so any HTTP client that understands Problem Details can parse the base members without Cloudflare-specific code.  
#### Breaking change  
The Markdown frontmatter field `http_status` has been renamed to `status`. Agents consuming Markdown frontmatter should update parsers accordingly.  
#### Changes  
**JSON format.** Clients sending `Accept: application/json` or `Accept: application/problem+json` now receive a structured JSON object with the same operational fields as Markdown frontmatter, plus RFC 9457 standard members.  
**RFC 9457 standard members (JSON only):**  
   * `type` — URI pointing to Cloudflare documentation for the specific error code  
   * `status` — HTTP status code (matching the response status)  
   * `title` — short, human-readable summary  
   * `detail` — human-readable explanation specific to this occurrence  
   * `instance` — Ray ID identifying this specific error occurrence  
**Field renames:**  
   * `http_status` \-> `status` (JSON and Markdown)  
   * `what_happened` \-> `detail` (JSON only — Markdown prose sections are unchanged)  
**Content-Type mirroring.** Clients sending `Accept: application/problem+json` receive `Content-Type: application/problem+json; charset=utf-8` back; `Accept: application/json` receives `application/json; charset=utf-8`. Same body in both cases.  
#### Negotiation behavior  
| Request header sent                           | Response format                              |  
| --------------------------------------------- | -------------------------------------------- |  
| Accept: application/json                      | JSON (application/json content type)         |  
| Accept: application/problem+json              | JSON (application/problem+json content type) |  
| Accept: application/json, text/markdown;q=0.9 | JSON                                         |  
| Accept: text/markdown                         | Markdown                                     |  
| Accept: text/markdown, application/json       | Markdown (equal q, first-listed wins)        |  
| Accept: \*/\*                                 | HTML (default)                               |  
#### Availability  
Available now for Cloudflare-generated 1xxx errors.  
#### Get started  
Terminal window  
```  
curl -s --compressed -H "Accept: application/json" -A "TestAgent/1.0" -H "Accept-Encoding: gzip, deflate" "<YOUR_DOMAIN>/cdn-cgi/error/1015" | jq .  
```  
Terminal window  
```  
curl -s --compressed -H "Accept: application/problem+json" -A "TestAgent/1.0" -H "Accept-Encoding: gzip, deflate" "<YOUR_DOMAIN>/cdn-cgi/error/1015" | jq .  
```  
References:  
   * [RFC 9457 — Problem Details for HTTP APIs ↗](https://www.rfc-editor.org/rfc/rfc9457)  
   * [Cloudflare 1xxx error documentation](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/)

Mar 11, 2026
1. ### [Ingest field selection for Log Explorer](https://developers.cloudflare.com/changelog/post/2026-03-11-ingest-field-selection/)  
[ Log Explorer ](https://developers.cloudflare.com/log-explorer/)  
Cloudflare Log Explorer now allows you to customize exactly which data fields are ingested and stored when enabling or managing log datasets.  
Previously, ingesting logs often meant taking an "all or nothing" approach to data fields. With **Ingest Field Selection**, you can now choose from a list of available and recommended fields for each dataset. This allows you to reduce noise, focus on the metrics that matter most to your security and performance analysis, and manage your data footprint more effectively.  
#### Key capabilities  
   * **Granular control:** Select only the specific fields you need when enabling a new dataset.  
   * **Dynamic updates:** Update fields for existing, already enabled logstreams at any time.  
   * **Historical consistency:** Even if you disable a field later, you can still query and receive results for that field for the period it was captured.  
   * **Data integrity:** Core fields, such as `Timestamp`, are automatically retained to ensure your logs remain searchable and chronologically accurate.  
#### Example configuration  
When configuring a dataset via the dashboard or API, you can define a specific set of fields. The `Timestamp` field remains mandatory to ensure data indexability.  
```  
{  
  "dataset": "firewall_events",  
  "enabled": true,  
  "fields": [  
    "Timestamp",  
    "ClientRequestHost",  
    "ClientIP",  
    "Action",  
    "EdgeResponseStatus",  
    "OriginResponseStatus"  
  ]  
}  
```  
For more information, refer to the [Log Explorer documentation](https://developers.cloudflare.com/log-explorer/).

Mar 10, 2026
1. ### [Audit logs (version 2) - General Availability](https://developers.cloudflare.com/changelog/post/2026-03-10-audit-logs-v2-ga/)  
[ Audit Logs ](https://developers.cloudflare.com/fundamentals/account/account-security/review-audit-logs/)  
Audit Logs v2 is now generally available to all Cloudflare customers.  
![Audit Logs v2 GA](https://developers.cloudflare.com/_astro/auditlogsv2.C3pqAR33_1qYU5j.webp)  
Audit Logs v2 provides a unified and standardized system for tracking and recording all user and system actions across Cloudflare products. Built on Cloudflare's API Shield / OpenAPI gateway, logs are generated automatically without requiring manual instrumentation from individual product teams, ensuring consistency across \~95% of Cloudflare products.  
**What's available at GA:**  
   * **Standardized logging** — Audit logs follow a consistent format across all Cloudflare products, making it easier to search, filter, and investigate activity.  
   * **Expanded product coverage** — \~95% of Cloudflare products covered, up from \~75% in v1.  
   * **Granular filtering** — Filter by actor, action type, action result, resource, raw HTTP method, zone, and more. Over 20 filter parameters available via the API.  
   * **Enhanced context** — Each log entry includes authentication method, interface (API or dashboard), Cloudflare Ray ID, and actor token details.  
   * **18-month retention** — Logs are retained for 18 months. Full history is accessible via the API or Logpush.  
**Access:**  
   * **Dashboard**: Go to **Manage Account** \> **Audit Logs**. Audit Logs v2 is shown by default.  
   * **API**: `GET https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit`  
   * **Logpush**: Available via the `audit_logs_v2` account-scoped dataset.  
**Important notes:**  
   * Approximately 30 days of logs from the Beta period (back to \~February 8, 2026) are available at GA. These Beta logs will expire on \~April 9, 2026\. Logs generated after GA will be retained for the full 18 months. Older logs remain available in Audit Logs v1.  
   * The UI query window is limited to 90 days for performance reasons. Use the API or Logpush for access to the full 18-month history.  
   * `GET` requests (view actions) and `4xx` error responses are not logged at GA. `GET` logging will be selectively re-enabled for sensitive read operations in a future release.  
   * Audit Logs v1 continues to run in parallel. A deprecation timeline will be communicated separately.  
   * Before and after values — the ability to see what a value changed from and to — is a highly requested feature and is on our roadmap for a post-GA release. In the meantime, we recommend using Audit Logs v1 for before and after values. Audit Logs v1 will continue to run in parallel until this feature is available in v2.  
For more details, refer to the [Audit Logs v2 documentation](https://developers.cloudflare.com/fundamentals/account/account-security/audit-logs/).

Mar 09, 2026
1. ### [New MCP Portal Logs dataset and new fields across multiple Logpush datasets in Cloudflare Logs](https://developers.cloudflare.com/changelog/post/2026-03-09-log-fields-updated/)  
[ Logs ](https://developers.cloudflare.com/logs/)  
Cloudflare has added new fields across multiple [Logpush datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/):  
#### New dataset  
   * **MCP Portal Logs**: A new dataset with fields including `ClientCountry`, `ClientIP`, `ColoCode`, `Datetime`, `Error`, `Method`, `PortalAUD`, `PortalID`, `PromptGetName`, `ResourceReadURI`, `ServerAUD`, `ServerID`, `ServerResponseDurationMs`, `ServerURL`, `SessionID`, `Success`, `ToolCallName`, `UserEmail`, and `UserID`.  
#### New fields in existing datasets  
   * **DEX Application Tests**: `HTTPRedirectEndMs`, `HTTPRedirectStartMs`, `HTTPResponseBody`, and `HTTPResponseHeaders`.  
   * **DEX Device State Events**: `ExperimentalExtra`.  
   * **Firewall Events**: `FraudUserID`.  
   * **Gateway HTTP**: `AppControlInfo` and `ApplicationStatuses`.  
   * **Gateway DNS**: `InternalDNSDurationMs`.  
   * **HTTP Requests**: `FraudEmailRisk`, `FraudUserID`, and `PayPerCrawlStatus`.  
   * **Network Analytics Logs**: `DNSQueryName`, `DNSQueryType`, and `PFPCustomTag`.  
   * **WARP Toggle Changes**: `UserEmail`.  
   * **WARP Config Changes**: `UserEmail`.  
   * **Zero Trust Network Session Logs**: `SNI`.  
For the complete field definitions for each dataset, refer to [Logpush datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/).

Feb 26, 2026
1. ### [Markdown responses for Cloudflare 1xxx errors](https://developers.cloudflare.com/changelog/post/2026-02-26-markdown-responses-for-1xxx-errors/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Cloudflare now returns structured Markdown responses for Cloudflare-generated 1xxx errors when clients send `Accept: text/markdown`.  
Each response includes YAML frontmatter plus guidance sections (`What happened` / `What you should do`) so agents can make deterministic retry and escalation decisions without parsing HTML.  
In measured 1,015 comparisons, Markdown reduced payload size and token footprint by over 98% versus HTML.  
Included frontmatter fields:  
   * `error_code`, `error_name`, `error_category`, `http_status`  
   * `ray_id`, `timestamp`, `zone`  
   * `cloudflare_error`, `retryable`, `retry_after` (when applicable), `owner_action_required`  
Default behavior is unchanged: clients that do not explicitly request Markdown continue to receive HTML error pages.  
#### Negotiation behavior  
Cloudflare uses standard HTTP content negotiation on the `Accept` header.  
   * `Accept: text/markdown` \-> Markdown  
   * `Accept: text/markdown, text/html;q=0.9` \-> Markdown  
   * `Accept: text/*` \-> Markdown  
   * `Accept: */*` \-> HTML (default browser behavior)  
When multiple values are present, Cloudflare selects the highest-priority supported media type using `q` values. If Markdown is not explicitly preferred, HTML is returned.  
#### Availability  
Available now for Cloudflare-generated 1xxx errors.  
#### Get started  
Terminal window  
```  
curl -H "Accept: text/markdown" https://<your-domain>/cdn-cgi/error/1015  
```  
Reference: [Cloudflare 1xxx error documentation](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/)

Feb 20, 2026
1. ### [Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard](https://developers.cloudflare.com/changelog/post/2026-02-20-tunnel-core-dashboard/)  
[ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Cloudflare Tunnel for SASE ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/)  
[Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) is now available in the main Cloudflare Dashboard at [Networking > Tunnels ↗](https://dash.cloudflare.com/?to=/:account/tunnels), bringing first-class Tunnel management to developers using Tunnel for securing origin servers.  
![Manage Tunnels in the Core Dashboard](https://developers.cloudflare.com/_astro/tunnel-core-dashboard.BGPqaHfo_Pi6HO.webp)  
This new experience provides everything you need to manage Tunnels for [public applications](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/), including:  
   * **Full Tunnel lifecycle management**: Create, configure, delete, and monitor all your Tunnels in one place.  
   * **Native integrations**: View Tunnels by name when configuring [DNS records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/) and [Workers VPC](https://developers.cloudflare.com/workers-vpc/) — no more copy-pasting UUIDs.  
   * **Real-time visibility**: Monitor [replicas](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/) and Tunnel [health status](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors/#tunnel-status) directly in the dashboard.  
   * **Routing map**: Manage all ingress routes for your Tunnel, including [public applications](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/), [private hostnames](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/), [private CIDRs](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-cidr/), and [Workers VPC services](https://developers.cloudflare.com/workers-vpc/), from a single interactive interface.  
#### Choose the right dashboard for your use case  
**Core Dashboard**: Navigate to [Networking > Tunnels ↗](https://dash.cloudflare.com/?to=/:account/tunnels) to manage Tunnels for:  
   * Securing origin servers and [public applications](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/) with CDN, WAF, Load Balancing, and DDoS protection  
   * Connecting [Workers to private services](https://developers.cloudflare.com/workers-vpc/) via Workers VPC  
**Cloudflare One Dashboard**: Navigate to [Zero Trust > Networks > Connectors ↗](https://one.dash.cloudflare.com/?to=/:account/networks/connectors) to manage Tunnels for:  
   * Securing your public applications with [Zero Trust access policies](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/self-hosted-public-app/)  
   * Connecting users to [private applications](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app/)  
   * Building a [private mesh network](https://developers.cloudflare.com/reference-architecture/architectures/sase/#connecting-networks)  
Both dashboards provide complete Tunnel management capabilities — choose based on your primary workflow.  
#### Get started  
New to Tunnel? Learn how to [get started with Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/) or explore advanced use cases like [securing SSH servers](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/) or [running Tunnels in Kubernetes](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/deployment-guides/kubernetes/).

Feb 18, 2026
1. ### [New cfWorker metric in Server-Timing header](https://developers.cloudflare.com/changelog/post/2026-02-18-cfworker-server-timing/)  
[ Analytics ](https://developers.cloudflare.com/analytics/)  
The Server-Timing header now includes a new `cfWorker` metric that measures time spent executing Cloudflare Workers, including any subrequests performed by the Worker. This helps developers accurately identify whether high Time to First Byte (TTFB) is caused by Worker processing or slow upstream dependencies.  
Previously, Worker execution time was included in the `edge` metric, making it harder to identify true edge performance. The new `cfWorker` metric provides this visibility:  
| Metric   | Description                                                                           |  
| -------- | ------------------------------------------------------------------------------------- |  
| edge     | Total time spent on the Cloudflare edge, including Worker execution                   |  
| origin   | Time spent fetching from the origin server                                            |  
| cfWorker | Time spent in Worker execution, including subrequests but excluding origin fetch time |  
#### Example response  
```  
Server-Timing: cdn-cache; desc=DYNAMIC, edge; dur=20, origin; dur=100, cfWorker; dur=7  
```  
In this example, the edge took 20ms, the origin took 100ms, and the Worker added just 7ms of processing time.  
#### Availability  
The `cfWorker` metric is enabled by default if you have [Real User Monitoring (RUM)](https://developers.cloudflare.com/web-analytics/) enabled. Otherwise, you can enable it using [Rules](https://developers.cloudflare.com/rules/).  
This metric is particularly useful for:  
   * **Performance debugging**: Quickly determine if latency is caused by Worker code, external API calls within Workers, or slow origins.  
   * **Optimization targeting**: Identify which component of your request path needs optimization.  
   * **Real User Monitoring (RUM)**: Access detailed timing breakdowns directly from response headers for client-side analytics.  
For more information about Server-Timing headers, refer to the [W3C Server Timing specification ↗](https://www.w3.org/TR/server-timing/).

Feb 16, 2026
1. ### [Content encoding support for Markdown for Agents and other improvements](https://developers.cloudflare.com/changelog/post/2026-02-16-markdown-for-agents-improvements/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
When AI systems request pages from any website that uses Cloudflare and has [Markdown for Agents](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/) enabled, they can express the preference for `text/markdown` in the request: our network will automatically and efficiently convert the HTML to markdown, when possible, on the fly.  
This release adds the following improvements:  
   * The origin response limit was raised from 1 MB to 2 MB (2,097,152 bytes).  
   * We no longer require the origin to send the `content-length` header.  
   * We now support content encoded responses from the origin.  
If you haven’t enabled automatic Markdown conversion yet, visit the [AI Crawl Control ↗](https://dash.cloudflare.com/?to=/:account/:zone/ai) section of the Cloudflare dashboard and enable **Markdown for Agents**.  
Refer to our [developer documentation](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/) for more details.

Feb 13, 2026
1. ### [Fine-grained permissions for Access policies and service tokens](https://developers.cloudflare.com/changelog/post/2026-02-13-access-policy-service-token-permissions/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)[ Access ](https://developers.cloudflare.com/cloudflare-one/access-controls/policies/)  
Fine-grained permissions for **Access policies** and **Access service tokens** are available. These new resource-scoped roles expand the existing RBAC model, enabling administrators to grant permissions scoped to individual resources.  
#### New roles  
   * **Cloudflare Access policy admin**: Can edit a specific [Access policy](https://developers.cloudflare.com/cloudflare-one/access-controls/policies/) in an account.  
   * **Cloudflare Access service token admin**: Can edit a specific [Access service token](https://developers.cloudflare.com/cloudflare-one/access-controls/service-credentials/service-tokens/) in an account.  
These roles complement the existing resource-scoped roles for Access applications, identity providers, and infrastructure targets.  
For more information:  
   * [Resource-scoped roles](https://developers.cloudflare.com/fundamentals/manage-members/roles/#resource-scoped-roles)  
   * [Role scopes](https://developers.cloudflare.com/fundamentals/manage-members/scope/)  
Note  
Resource-scoped roles is currently in beta.

Feb 13, 2026
1. ### [Cloudflare Python SDK v5.0.0-beta.1 now available](https://developers.cloudflare.com/changelog/post/2026-02-13-cloudflare-python-v500-beta1/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)[ SDK ](https://developers.cloudflare.com/sdk/)  
> **Disclaimer:** Please note that v5.0.0-beta.1 is in Beta and we are still testing it for stability.  
Full Changelog: [v4.3.1...v5.0.0-beta.1 ↗](https://github.com/cloudflare/cloudflare-python/compare/v4.3.1...v5.0.0-beta.1)  
In this release, you'll see a large number of breaking changes. This is primarily due to a change in OpenAPI definitions, which our libraries are based off of, and codegen updates that we rely on to read those OpenAPI definitions and produce our SDK libraries. As the codegen is always evolving and improving, so are our code bases.  
There may be changes that are not captured in this changelog. Feel free to open an issue to report any inaccuracies, and we will make sure it gets into the changelog before the v5.0.0 release.  
Most of the breaking changes below are caused by improvements to the accuracy of the base OpenAPI schemas, which sometimes translates to breaking changes in downstream clients that depend on those schemas.  
Please ensure you read through the list of changes below and the migration guide before moving to this version - this will help you understand any down or upstream issues it may cause to your environments.  
#### Breaking Changes  
**The following resources have breaking changes. See the [v5 Migration Guide ↗](https://github.com/cloudflare/cloudflare-python/blob/main/docs/v5-migration-guide.md) for detailed migration instructions.**  
   * `abusereports`  
   * `acm.totaltls`  
   * `apigateway.configurations`  
   * `cloudforceone.threatevents`  
   * `d1.database`  
   * `intel.indicatorfeeds`  
   * `logpush.edge`  
   * `origintlsclientauth.hostnames`  
   * `queues.consumers`  
   * `radar.bgp`  
   * `rulesets.rules`  
   * `schemavalidation.schemas`  
   * `snippets`  
   * `zerotrust.dlp`  
   * `zerotrust.networks`  
#### Features  
#### New API Resources  
   * `abusereports` \- Abuse report management  
   * `abusereports.mitigations` \- Abuse report mitigation actions  
   * `ai.tomarkdown` \- AI-powered markdown conversion  
   * `aigateway.dynamicrouting` \- AI Gateway dynamic routing configuration  
   * `aigateway.providerconfigs` \- AI Gateway provider configurations  
   * `aisearch` \- AI-powered search functionality  
   * `aisearch.instances` \- AI Search instance management  
   * `aisearch.tokens` \- AI Search authentication tokens  
   * `alerting.silences` \- Alert silence management  
   * `brandprotection.logomatches` \- Brand protection logo match detection  
   * `brandprotection.logos` \- Brand protection logo management  
   * `brandprotection.matches` \- Brand protection match results  
   * `brandprotection.queries` \- Brand protection query management  
   * `cloudforceone.binarystorage` \- CloudForce One binary storage  
   * `connectivity.directory` \- Connectivity directory services  
   * `d1.database` \- D1 database management  
   * `diagnostics.endpointhealthchecks` \- Endpoint health check diagnostics  
   * `fraud` \- Fraud detection and prevention  
   * `iam.sso` \- IAM Single Sign-On configuration  
   * `loadbalancers.monitorgroups` \- Load balancer monitor groups  
   * `organizations` \- Organization management  
   * `organizations.organizationprofile` \- Organization profile settings  
   * `origintlsclientauth.hostnamecertificates` \- Origin TLS client auth hostname certificates  
   * `origintlsclientauth.hostnames` \- Origin TLS client auth hostnames  
   * `origintlsclientauth.zonecertificates` \- Origin TLS client auth zone certificates  
   * `pipelines` \- Data pipeline management  
   * `pipelines.sinks` \- Pipeline sink configurations  
   * `pipelines.streams` \- Pipeline stream configurations  
   * `queues.subscriptions` \- Queue subscription management  
   * `r2datacatalog` \- R2 Data Catalog integration  
   * `r2datacatalog.credentials` \- R2 Data Catalog credentials  
   * `r2datacatalog.maintenanceconfigs` \- R2 Data Catalog maintenance configurations  
   * `r2datacatalog.namespaces` \- R2 Data Catalog namespaces  
   * `radar.bots` \- Radar bot analytics  
   * `radar.ct` \- Radar certificate transparency data  
   * `radar.geolocations` \- Radar geolocation data  
   * `realtimekit.activesession` \- Real-time Kit active session management  
   * `realtimekit.analytics` \- Real-time Kit analytics  
   * `realtimekit.apps` \- Real-time Kit application management  
   * `realtimekit.livestreams` \- Real-time Kit live streaming  
   * `realtimekit.meetings` \- Real-time Kit meeting management  
   * `realtimekit.presets` \- Real-time Kit preset configurations  
   * `realtimekit.recordings` \- Real-time Kit recording management  
   * `realtimekit.sessions` \- Real-time Kit session management  
   * `realtimekit.webhooks` \- Real-time Kit webhook configurations  
   * `tokenvalidation.configuration` \- Token validation configuration  
   * `tokenvalidation.rules` \- Token validation rules  
   * `workers.beta` \- Workers beta features  
#### New Endpoints (Existing Resources)  
#### `acm.totaltls`  
   * `edit()`  
   * `update()`  
#### `cloudforceone.threatevents`  
   * `list()`  
#### `contentscanning`  
   * `create()`  
   * `get()`  
   * `update()`  
#### `dns.records`  
   * `scan_list()`  
   * `scan_review()`  
   * `scan_trigger()`  
#### `intel.indicatorfeeds`  
   * `create()`  
   * `delete()`  
   * `list()`  
#### `leakedcredentialchecks.detections`  
   * `get()`  
#### `queues.consumers`  
   * `list()`  
#### `radar.ai`  
   * `summary()`  
   * `timeseries()`  
   * `timeseries_groups()`  
#### `radar.bgp`  
   * `changes()`  
   * `snapshot()`  
#### `workers.subdomains`  
   * `delete()`  
#### `zerotrust.networks`  
   * `create()`  
   * `delete()`  
   * `edit()`  
   * `get()`  
   * `list()`  
#### General Fixes and Improvements  
#### Type System & Compatibility  
   * **Type inference improvements**: Allow Pyright to properly infer TypedDict types within SequenceNotStr  
   * **Type completeness**: Add missing types to method arguments and response models  
   * **Pydantic compatibility**: Ensure compatibility with Pydantic versions prior to 2.8.0 when using additional fields  
#### Request/Response Handling  
   * **Multipart form data**: Correctly handle sending multipart/form-data requests with JSON data  
   * **Header handling**: Do not send headers with default values set to omit  
   * **GET request headers**: Don't send Content-Type header on GET requests  
   * **Response body model accuracy**: Broad improvements to the correctness of models  
#### Parsing & Data Processing  
   * **Discriminated unions**: Correctly handle nested discriminated unions in response parsing  
   * **Extra field types**: Parse extra field types correctly  
   * **Empty metadata**: Ignore empty metadata fields during parsing  
   * **Singularization rules**: Update resource name singularization rules for better consistency

Feb 12, 2026
1. ### [Introducing Markdown for Agents](https://developers.cloudflare.com/changelog/post/2026-02-12-markdown-for-agents/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Cloudflare's network now supports real-time content conversion at the source, for enabled zones using [content negotiation ↗](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Content%5Fnegotiation) headers. When AI systems request pages from any website that uses Cloudflare and has Markdown for Agents enabled, they can express the preference for `text/markdown` in the request: our network will automatically and efficiently convert the HTML to markdown, when possible, on the fly.  
Here is a curl example with the `Accept` negotiation header requesting this page from our developer documentation:  
Terminal window  
```  
curl https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ \  
  -H "Accept: text/markdown"  
```  
The response to this request is now formatted in markdown:  
```  
HTTP/2 200  
date: Wed, 11 Feb 2026 11:44:48 GMT  
content-type: text/markdown; charset=utf-8  
content-length: 2899  
vary: accept  
x-markdown-tokens: 725  
content-signal: ai-train=yes, search=yes, ai-input=yes  
---  
title: Markdown for Agents · Cloudflare Agents docs  
---  
## What is Markdown for Agents  
Markdown has quickly become the lingua franca for agents and AI systems  
as a whole. The format’s explicit structure makes it ideal for AI processing,  
ultimately resulting in better results while minimizing token waste.  
...  
```  
Refer to our [developer documentation](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/) and our [blog announcement ↗](https://blog.cloudflare.com/markdown-for-agents/) for more details.

Feb 12, 2026
1. ### [Terraform v5.17.0 now available](https://developers.cloudflare.com/changelog/post/2026-02-12-terraform-v5170-provider/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)[ Terraform ](https://developers.cloudflare.com/terraform/)  
In January 2025, we announced the launch of the new Terraform v5 Provider. We greatly appreciate the proactive engagement and valuable feedback from the Cloudflare community following the v5 release. In response, we have established a consistent and rapid [2-3 week cadence ↗](https://github.com/cloudflare/terraform-provider-cloudflare/issues/5774) for releasing targeted improvements, demonstrating our commitment to stability and reliability.  
With the help of the community, we have a growing number of resources that we have marked as [stable ↗](https://github.com/cloudflare/terraform-provider-cloudflare/issues/6237), with that list continuing to grow with every release. The most used [resources ↗](https://github.com/cloudflare/terraform-provider-cloudflare/issues/6237) are on track to be stable by the end of March 2026, when we will also be releasing a new migration tool to help you migrate from v4 to v5 with ease.  
This release brings new capabilities for AI Search, enhanced Workers Script placement controls, and numerous bug fixes based on community feedback. We also begun laying foundational work for improving the v4 to v5 migration process. Stay tuned for more details as we approach the March 2026 release timeline.  
Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.  
#### Features  
   * **ai\_search\_instance:** add data source for querying AI Search instances  
   * **ai\_search\_token:** add data source for querying AI Search tokens  
   * **account:** add support for tenant unit management with new `unit` field  
   * **account:** add automatic mapping from `managed_by.parent_org_id` to `unit.id`  
   * **authenticated\_origin\_pulls\_certificate:** add data source for querying authenticated origin pull certificates  
   * **authenticated\_origin\_pulls\_hostname\_certificate:** add data source for querying hostname-specific authenticated origin pull certificates  
   * **authenticated\_origin\_pulls\_settings:** add data source for querying authenticated origin pull settings  
   * **workers\_kv:** add `value` field to data source to retrieve KV values directly  
   * **workers\_script:** add `script` field to data source to retrieve script content  
   * **workers\_script:** add support for `simple` rate limit binding  
   * **workers\_script:** add support for targeted placement mode with `placement.target` array for specifying placement targets (region, hostname, host)  
   * **workers\_script:** add `placement_mode` and `placement_status` computed fields  
   * **zero\_trust\_dex\_test:** add data source with filter support for finding specific tests  
   * **zero\_trust\_dlp\_predefined\_profile:** add `enabled_entries` field for flexible entry management  
#### Bug Fixes  
   * **account:** map `managed_by.parent_org_id` to `unit.id` in unmarshall and add acceptance tests  
   * **authenticated\_origin\_pulls\_certificate:** add certificate normalization to prevent drift  
   * **authenticated\_origin\_pulls:** handle array response and implement full lifecycle  
   * **authenticated\_origin\_pulls\_hostname\_certificate:** fix resource and tests  
   * **cloudforce\_one\_request\_message:** use correct `request_id` field instead of `id` in API calls  
   * **dns\_zone\_transfers\_incoming:** use correct `zone_id` field instead of `id` in API calls  
   * **dns\_zone\_transfers\_outgoing:** use correct `zone_id` field instead of `id` in API calls  
   * **email\_routing\_settings:** use correct `zone_id` field instead of `id` in API calls  
   * **hyperdrive\_config:** add proper handling for write-only fields to prevent state drift  
   * **hyperdrive\_config:** add normalization for empty `mtls` objects to prevent unnecessary diffs  
   * **magic\_network\_monitoring\_rule:** use correct `account_id` field instead of `id` in API calls  
   * **mtls\_certificates:** fix resource and test  
   * **pages\_project:** revert build\_config to computed optional  
   * **stream\_key:** use correct `account_id` field instead of `id` in API calls  
   * **total\_tls:** use upsert pattern for singleton zone setting  
   * **waiting\_room\_rules:** use correct `waiting_room_id` field instead of `id` in API calls  
   * **workers\_script:** add support for placement mode/status  
   * **zero\_trust\_access\_application:** update v4 version on migration tests  
   * **zero\_trust\_device\_posture\_rule:** update tests to match API  
   * **zero\_trust\_dlp\_integration\_entry:** use correct `entry_id` field instead of `id` in API calls  
   * **zero\_trust\_dlp\_predefined\_entry:** use correct `entry_id` field instead of `id` in API calls  
   * **zero\_trust\_organization:** fix plan issues  
#### Chores  
   * add state upgraders to 95+ resources to lay the foundation for replacing Grit (still under active development)  
   * **certificate\_pack:** add state migration handler for SDKv2 to Framework conversion  
   * **custom\_hostname\_fallback\_origin:** add comprehensive lifecycle test and migration support  
   * **dns\_record:** add state migration handler for SDKv2 to Framework conversion  
   * **leaked\_credential\_check:** add import functionality and tests  
   * **load\_balancer\_pool:** add state migration handler with detection for v4 vs v5 format  
   * **pages\_project:** add state migration handlers  
   * **tiered\_cache:** add state migration handlers  
   * **zero\_trust\_dlp\_predefined\_profile:** deprecate `entries` field in favor of `enabled_entries`  
#### For more information  
   * [Terraform Provider ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs)  
   * [Documentation on using Terraform with Cloudflare](https://developers.cloudflare.com/terraform/)  
   * [List of stabilized resources ↗](https://github.com/cloudflare/terraform-provider-cloudflare/issues/6237)

Feb 09, 2026
1. ### [Analytics enhancements](https://developers.cloudflare.com/changelog/post/2026-02-09-analytics-enhancements/)  
[ AI Crawl Control ](https://developers.cloudflare.com/ai-crawl-control/)  
AI Crawl Control metrics have been enhanced with new views, improved filtering, and better data visualization.  
![AI Crawl Control path patterns](https://developers.cloudflare.com/_astro/ai-crawl-control-path-patterns.0xT_lucE_1Png6i.webp)  
**Path pattern grouping**  
   * In the **Metrics** tab > **Most popular paths** table, use the new **Patterns** tab that groups requests by URI pattern (`/blog/*`, `/api/v1/*`, `/docs/*`) to identify which site areas crawlers target most. Refer to the screenshot above.  
**Enhanced referral analytics**  
   * Destination patterns show which site areas receive AI-driven referral traffic.  
   * In the **Metrics** tab, a new **Referrals over time** chart shows trends by operator or source.  
**Data transfer metrics**  
   * In the **Metrics** tab > **Allowed requests over time** chart, toggle **Bytes** to show bandwidth consumption.  
   * In the **Crawlers** tab, a new **Bytes Transferred** column shows bandwidth per crawler.  
**Image exports**  
   * Export charts and tables as images for reports and presentations.  
Learn more about [analyzing AI traffic](https://developers.cloudflare.com/ai-crawl-control/features/analyze-ai-traffic/).

[Search all changelog entries](https://developers.cloudflare.com/search/?contentType=Changelog+entry)