Core Platform Updates & Release Notes

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

In the tunnel detail view, a new Live logs tab lets you:

• Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
• Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.

Go to Tunnels ↗

For more information, refer to Monitor tunnels and Tunnel log streams.

Original source

OAuth consent screens now display a shield icon with explanatory text beneath the consent screen title. Each shield icon indicates who owns the application and whether its domain ownership is verified.

• Green filled shield: Cloudflare owns and manages the application.
• Blue outlined shield: A third-party application with verified ownership of its domain.
• Amber filled shield: A third-party application without verified ownership of a domain.
• Domain verification only confirms that the application owner controls the displayed domain.
• For more information, refer to Authorizing an application.

Original source

Limitations

You can now create standalone Free accounts directly from the Cloudflare dashboard using the new Create Account button. This feature is currently available to all users.

When creating a Free account:

• You can create up to 5 Free accounts.
• Your user account must have at least 7 days of tenure to be eligible.
• The account is created immediately and ready to use.

To create a Free account, go to the Cloudflare dashboard ↗ and select Create Account from either the account switcher in the top left (where your account name appears) or from the Accounts page.

This feature can only be used to create a Cloudflare Free account. To create an Enterprise Account under your existing contract, please contact Cloudflare Support.

All users can create a Cloudflare Free account, however, Enterprises wish to restrict this action to only Super Administrators. We will deliver this improvement in a future release.

Next steps

After creating your Free account, you can:

• Add a payment method to enable additional Cloudflare products and services.
• Update billing information to manage payment methods, billing address, or tax IDs.
• Review how Cloudflare billing works to understand the billing lifecycle and charge types.
• Assign accounts to an Enterprise Organization to centrally manage multiple accounts from a single dashboard.

Original source

Audit Logs v2 now includes Resource History. For any audit log entry, you can see the sequence of previous changes to the same resource and view a side-by-side diff of what was modified.

Resource History uses the audit log entries you already have. There is no additional configuration, no backend recapture, and no changes to how audit logs are generated.

Dashboard

Go to Manage Account > Audit Logs.

Open any audit log entry.

Select the History tab to see the full history for that resource.

Select any earlier entry to see a side-by-side diff of the fields that changed between it and the current entry.

API

Use the History endpoint to retrieve the change history for any audit log entry:

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

The endpoint is also available for organization-scoped audit logs at /organizations/{organization_id}/logs/audit/{id}/history.

For more information, refer to the Resource History documentation.

Original source

The Account Roles API is deprecated and is being replaced by the Permission Groups API. An end of life date has not yet been established.

What you need to do

Review the Permission Groups API documentation; the response schema differs from the legacy Roles response.

Highlights

Integrations migrating to the Permission Groups API must obtain Permission Group IDs from that API and use them in the Account Members API policies request shape. Integrations that persist legacy Role IDs will need to remap their assignments.

The legacy Role response includes a top-level description and a permissions object keyed by resource type with edit/read flags.

The PermissionGroup response replaces those with a meta object containing label and scopes. Individual permissions are not returned as part of the permission group.

The new API supports the API Token authorization scheme. The legacy Email + API Key authorization schema is provided for backwards compatibility.

For more information, refer to API deprecations.

Original source

We are turning on budget alerts by default for eligible Pay-as-you-go accounts. If your account does not already have a budget alert, Cloudflare will create one for you with a $10 account-level threshold. Your default alert will enable at the turn of your next billing cycle, so it will not fire based on usage you have already incurred.

We are rolling this out in cohorts over the coming weeks, so eligible accounts may see their default alert appear at different times.

The default alert behaves exactly like an alert you would create yourself. When your cumulative usage-based spend this cycle reaches the threshold, you receive an email notification. The alert is informational only. It does not cap your usage or impact your account in any way.

Usage is processed once per day for the prior day's activity, so budget alerts fire the day after the threshold is reached rather than in real time.

Budget alerts only consider spend on usage-based products. Recurring subscription fees, such as the Workers Paid plan fee or other monthly plan charges, are not included in the threshold calculation.

You can change the threshold, add additional alerts, or remove the default alert entirely from Manage Account > Billing > Billable Usage, or from your Notifications settings. If you already configured your own budget alert, nothing changes.

Enterprise contract accounts are not in scope.

For more information, refer to the Budget alerts documentation.

Original source

Distributor, MSSP, and Agency partners on Cloudflare Organizations can now add and manage Organization Members directly from the Cloudflare dashboard, without help from Cloudflare.

Previously, adding a member to a Distributor, MSSP, or Agency Organization was a manual, Cloudflare-assisted process that required a request to Cloudflare and enrollment in a closed beta, and the dashboard Add member flow was blocked for these Organizations.

Now, Organization admins can add members themselves from Organization > Members > Add member, with no beta enrollment required.

New members receive access to the Organization's accounts through the same implicit-access model already used for enterprise Organizations. The Accounts list and the account switcher classify Distributor, MSSP, and Agency Organizations consistently with enterprise Organizations, so their accounts are labeled and grouped correctly in the dashboard.

Agency partners also gain access to the Organizations dashboard, while retaining access to their existing Tenant management dashboard.

Distributor, MSSP, and Agency Organizations are currently in beta.

For more information, refer to Manage Organization members.

Original source

Bot management fields and ASN support in Cache Rules

Cache Rules now supports bot management fields and the ip.src.asnum field in expression filters. You can now build cache policies that differentiate between automated and human traffic, or segment caching behavior by autonomous system number (ASN).

This allows you to apply different caching strategies for verified bots, high-risk traffic, or specific network operators without affecting legitimate user requests. For example, you can set shorter cache TTLs for suspected bot traffic or bypass cache entirely for requests from specific ASNs.

New fields

The following fields are now available in Cache Rules expressions:

Field Type Description cf.bot_management.score Number Bot score from 1 to 99, where a lower value indicates a higher likelihood that the request originates from a bot. cf.bot_management.ja3_hash String JA3 fingerprint of the request, which helps identify the client making the connection. cf.bot_management.ja4 String JA4 fingerprint of the request, which provides a more detailed client identification than JA3. cf.bot_management.verified_bot Boolean Whether the request originates from a verified bot, such as a search engine crawler. cf.bot_management.static_resource Boolean Whether the request is for a static resource and therefore exempt from bot detection. cf.bot_management.js_detection.passed Boolean Whether the browser passed JavaScript detection when the feature is enabled. cf.bot_management.attack_score Number Classifies the request by attack score, from 1 (likely automated) to 99 (likely human). cf.bot_management.api_score Number Classifies the request by API score, from 1 (likely automated) to 99 (likely human). cf.bot_management.bot_tags["<TAG>"] Boolean Whether the bot traffic matches the specified tag, such as google or bing. cf.bot_management.corporate_proxy Boolean Whether the request originates from a known corporate proxy. ip.src.asnum Number The autonomous system number (ASN) of the incoming request's IP address.

Note

Bot management fields require a Bot Management subscription. ip.src.asnum is available on all plans.

Example

Cache Rules expressions support combining these fields with other criteria. The following example sets a shorter cache TTL for API requests that originate from a high-risk bot or an unexpected ASN:

(http.request.uri.path contains "/api/" and cf.bot_management.score lt 30)
or
(http.request.uri.path contains "/api/" and not ip.src.asnum in {12345 67890})

To learn more, refer to the Cache Rules documentation and the Fields reference.

Original source

Markdown for Agents now preserves security- and cache-relevant response headers from your origin when converting HTML to Markdown

Markdown for Agents preserves security headers such as Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, Set-Cookie, and CORS headers (for example, Access-Control-Allow-Origin) on the converted response.

Caching headers (Cache-Control, Expires, Age) continue to pass through.

Your origin's Content Signals policy is now authoritative. If your origin sets a content-signal header, Markdown for Agents preserves it. When the origin does not send one, Cloudflare adds the default Content-Signal: ai-train=yes, search=yes, ai-input=yes.

This release also fixes relative link resolution for directory-style base URLs (those ending in a trailing slash). Previously, relative links such as ../page/ could resolve one path segment too high and return a 404. Links are now resolved correctly per RFC 3986.

Refer to our developer documentation for more details.

Original source

Route endpoints

On October 5, 2026, two changes take effect across the Zero Trust Networks API and Cloudflare Tunnel API: the CIDR-encoded route endpoints are removed, and tunnel list and get responses no longer include the connections field. If you manage private network routes or read tunnel connection details through the API, cloudflared, Terraform, or another integration, review the changes in the following sections and migrate before the removal date.

The CIDR-encoded route endpoints are deprecated in favor of the standard, route_id-based endpoints that already exist today. Both sets of endpoints route a private network through Cloudflare Tunnel or Cloudflare Mesh (the API still refers to Mesh nodes as warp_connector) — only the request shape changes.

Deprecated endpoints (removed October 5, 2026):

• Create a tunnel route (CIDR Endpoint): POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• Update a tunnel route (CIDR Endpoint): PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• Delete a tunnel route (CIDR Endpoint): DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}

Replacement endpoints:

• Create a tunnel route: POST /accounts/{account_id}/teamnet/routes
• Update a tunnel route: PATCH /accounts/{account_id}/teamnet/routes/{route_id}
• Delete a tunnel route: DELETE /accounts/{account_id}/teamnet/routes/{route_id}

What is changing

Deprecated (CIDR-encoded path)

Replacement

Route identifier

URL-encoded CIDR in the path (/network/{ip_network_encoded})

route_id in the path (network moves to the request body on create)

Create

POST .../teamnet/routes/network/{ip_network_encoded}

POST .../teamnet/routes with network and tunnel_id in the body

Update

PATCH .../teamnet/routes/network/{ip_network_encoded}

PATCH .../teamnet/routes/{route_id}

Delete

DELETE .../teamnet/routes/network/{ip_network_encoded}

DELETE .../teamnet/routes/{route_id}

Action required

Capture each route's route_id by calling List tunnel routes, or read it from the response the first time you create a route with the replacement endpoint.

Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.

If you manage routes with the cloudflared tunnel route ip add | delete commands, upgrade cloudflared to the latest version.

If you manage routes with Terraform, make sure you are on a current version of the cloudflare_zero_trust_tunnel_cloudflared_route resource and the Cloudflare Terraform provider.

# Before: create a route by URL-encoding the CIDR into the path
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: create a route with the network in the request body
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: update or delete a route using its route_id
curl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-d '{"comment": "Updated comment for this route."}'
curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Cloudflare Tunnel and Cloudflare Mesh connections

Starting the same day, the connections array is removed from list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (the cfd_tunnel and warp_connector API resources). Query the dedicated connections endpoint instead of reading the field off the tunnel or node object.

This affects:

• GET /accounts/{account_id}/cfd_tunnel — connections removed from each item in result
• GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — connections removed from result
• GET /accounts/{account_id}/warp_connector — connections removed from each item in result
• GET /accounts/{account_id}/warp_connector/{tunnel_id} — connections removed from result

Action required

Fetch connection details from the tunnel-specific connections endpoint instead of parsing it off the list or get response. For Cloudflare Tunnel, call GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections. For Cloudflare Mesh, call GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections.

# Before: read connections off the tunnel object
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

# After: query connections directly
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Update any dashboards, monitoring scripts, or automation that parses connections from the tunnel list or get response. cloudflared and the Cloudflare Terraform provider do not read this field, so no changes are required on their side for this part of the update.

Why we are making these changes

Smaller, faster responses. Cloudflare Tunnel and Cloudflare Mesh nodes with many connections no longer inflate every list and get call — connection detail is only fetched when you need it.

A single way to identify a route. Consolidating on route_id removes the need to URL-encode CIDR ranges into the path and matches how every other resource in the Zero Trust Networks API is addressed.

Consistency across the API. Both changes align these endpoints with Cloudflare's standard REST conventions for resource identifiers and nested detail endpoints.

To learn more, refer to the Zero Trust Networks API, the Cloudflare Tunnel API, and Routes documentation.

Original source

Enterprise customers can now push per-connection WebSocket analytics to any Logpush destination using the new websocket_analytics dataset. Each log record is emitted when a WebSocket connection closes and includes fields that were previously only available to Cloudflare engineers via internal tooling.

Key fields include

• ConnectionCloseReason — why the connection ended: peerReset, peerNoError, timedOut, upstreamReset, protocolViolation, unspecifiedError, or none.
• ConnectionCloseSource — which side initiated the close: upstream, downstream, me, or both.
• ConnectionTransportCloseCode — the TLS alert code or TCP-level close code for additional precision.
• RayID — correlate WebSocket connection events with your existing HTTP Request logs.

The dataset also includes directional byte counts (BytesSentClient, BytesReceivedClient, BytesSentOrigin, BytesReceivedOrigin), connection timestamps, client IP, colo code, and request metadata from the original WebSocket upgrade.

This data lets you build alerts on connection close patterns — for example, detecting spikes in TCP resets (ConnectionCloseReason == "peerReset") grouped by host and data center — directly in your existing log analysis tools.

For the full list of available fields, refer to WebSocket Analytics.

Original source

You can now assign granular, resource-scoped roles for Cloudflare Gateway firewall policies and Zero Trust lists. Administrators can delegate access to specific policy types or list management without granting account-wide or product-wide control.

What is new

When you add a member or create a permission policy, the following resource-scoped roles are now available:

Role Description Zero Trust Gateway Firewall Policies Admin Can view and edit all Gateway firewall policies, including DNS, HTTP, and Network policies. Zero Trust Gateway DNS Policies Admin Can view and edit Gateway DNS policies. Zero Trust Gateway HTTP Policies Admin Can view and edit Gateway HTTP policies. Zero Trust Gateway Network Policies Admin Can view and edit Gateway Network policies. Zero Trust Gateway Egress Policies Admin Can view and edit Gateway Egress policies. Zero Trust Gateway Resolver Policies Admin Can view and edit Gateway Resolver policies. Zero Trust Gateway Policies Admin Can view and edit all Gateway policies. Zero Trust Gateway Policies Read Can view all Gateway policies. Zero Trust Gateway Read Only Can view all Gateway resources. Zero Trust DNS Locations Admin Can view and edit DNS locations. Zero Trust Proxy Endpoints Admin Can view and edit Gateway Proxy Endpoints. Zero Trust Account Lists Admin Can view and edit all Gateway and Access lists. Zero Trust Account Lists Read Can view all Gateway and Access lists.

These roles allow you to:

• Grant a network engineer write access to Network policies only, without exposing DNS or HTTP policy configuration.
• Allow a security analyst to view all Gateway policies in read-only mode for auditing purposes.
• Delegate list management to a team that maintains block and allow lists without giving them access to policy configuration.

You can also now assign Resource-scoped roles. These roles are complementary to existing account-level roles, and allow you to grant access to a specific resource, like an individual Gateway policy or Cloudflare One list. Existing account-level roles continue to work. A member with the Cloudflare Gateway or Cloudflare Zero Trust role retains full access to all Gateway resources. This ensures backward compatibility for existing automation and API tokens.

Get started

Review the resource-scoped roles on the Cloudflare role reference.

Learn how to create permission policies that use these roles.

Original source

Cloudflare Logpush now supports firewall events as an account-scoped dataset. Configure a single Logpush job at the account level to receive firewall events for every zone in the account, instead of creating and maintaining a separate job per zone.

The dataset includes a new ZoneName field so you can identify which zone each event came from when consuming logs in your downstream pipeline.

What's available

• A new account-scoped firewall_events dataset, configurable via the Logpush API or the Cloudflare dashboard.
• The same fields and filter expressions supported by the existing zone-scoped firewall events dataset, plus the new ZoneName field.
• Support for all existing Logpush destinations.

Original source

Cloudflare has updated Logpush datasets:

New datasets

WebSocket Analytics: A new dataset with fields including BytesReceivedClient, BytesReceivedOrigin, BytesSentClient, BytesSentOrigin, ClientASN, ClientIP, ClientRequestHost, ClientRequestPath, ClientRequestUserAgent, ColoCode, ConnectionCloseReason, ConnectionCloseSource, ConnectionID, ConnectionTransportCloseCode, EdgeEndTimestamp, EdgeStartTimestamp, and RayID.

Updated fields in existing datasets

Firewall events (added): ZoneName. The Firewall events dataset is now also available for account-scope Logpush, in addition to the existing zone scope.

Email Security Alerts (added): BCC, DKIMResult, DMARCPolicy, DMARCResult, and SPFResult.

For the complete field definitions for each dataset, refer to Logpush datasets.

Original source