Directly from Log Search results, customers can pivot to other parts of the Cloudflare dashboard to immediately take action as a result of their investigation.
From the http_requests or fw_events dataset results, right click on an IP Address or JA3 Fingerprint to pivot to the Investigate portal to lookup the reputation of an IP address or JA3 fingerprint.
Easily learn about error codes by linking directly to our documentation from the EdgeResponseStatus or OriginResponseStatus fields.
From the gateway_http dataset, click on a policyid to link directly to the Zero Trust dashboard to review or make changes to a specific Gateway policy.
Two-factor authentication is the best way to help protect your account from account takeovers, but if you lose your second factor, you could be locked out of your account. Lock outs are one of the top reasons customers contact Cloudflare support, and our policies often don't allow us to bypass two-factor authentication for customers that are locked out. Today we are releasing an improvement where Cloudflare will periodically remind you to securely save your backup codes so you don't get locked out in the future.
Cloudflare's API now supports rate limiting headers using the pattern developed by the IETF draft on rate limiting ↗. This allows API consumers to know how many more calls are left until the rate limit is reached, as well as how long you will need to wait until more capacity is available.
Our SDKs automatically work with these new headers, backing off when rate limits are approached. There is no action required for users of the latest Cloudflare SDKs to take advantage of this.
As always, if you need any help with rate limits, please contact Support.
Changes
New Headers
Headers that are always returned:
Ratelimit: List of service limit items, composed of the limit name, the remaining quota (r) and the time next window resets (t). For example: "default";r=50;t=30
Ratelimit-Policy: List of quota policy items, composed of the policy name, the total quota (q) and the time window the quota applies to (w). For example: "burst";q=100;w=60
Returned only when a rate limit has been reached (error code: 429):
Retry-After: Number of Seconds until more capacity is available, rounded up
SDK Back offs
All of Cloudflare's latest SDKs will automatically respond to the headers, instituting a backoff when limits are approached.
GraphQL and Edge APIs
These new headers and back offs are only available for Cloudflare REST APIs, and will not affect GraphQL.
Create a custom field to log desired header or cookie values into the http_requests dataset and Log Explorer will import these as searchable fields. Once configured, use the custom SQL editor in Log Explorer to view or filter on these requests.
Starting December 1, 2025, list endpoints for the Cloudflare Tunnel API and Zero Trust Networks API will no longer return deleted tunnels, routes, subnets and virtual networks by default. This change makes the API behavior more intuitive by only returning active resources unless otherwise specified.
No action is required if you already explicitly set is_deleted=false or if you only need to list active resources.
The default behavior of the is_deleted query parameter will be updated.
Scenario
Previous behavior (before December 1, 2025)
New behavior (from December 1, 2025)
is_deleted parameter is omitted
Returns active & deleted tunnels, routes, subnets and virtual networks
Returns only active tunnels, routes, subnets and virtual networks
Action required
If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include the is_deleted parameter before December 1, 2025.
To get a list of only deleted resources, you must now explicitly add the is_deleted=true query parameter to your request:
# Example: Get ONLY deleted Tunnelscurl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true" \ -H "Authorization: Bearer $API_TOKEN"# Example: Get ONLY deleted Virtual Networkscurl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true" \ -H "Authorization: Bearer $API_TOKEN"
Following this change, retrieving a complete list of both active and deleted resources will require two separate API calls: one to get active items (by omitting the parameter or using is_deleted=false) and one to get deleted items (is_deleted=true).
Why we’re making this change
This update is based on user feedback and aims to:
Create a more intuitive default: Aligning with common API design principles where list operations return only active resources by default.
Reduce unexpected results: Prevents users from accidentally operating on deleted resources that were returned unexpectedly.
Improve performance: For most users, the default query result will now be smaller and more relevant.
Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2 week cadence to ensure its stability and reliability, including the v5.9 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach - we will be focusing on specific resources for every release, stabilizing the release, and closing all associated bugs with that resource before moving onto resolving migration issues.
Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.
This release includes a new resource, cloudflare_snippet, which replaces cloudflare_snippets. cloudflare_snippet is now considered deprecated but can still be used. Please utilize cloudflare_snippet as soon as possible.
Changes
Resources stabilized:
cloudflare_zone_setting
cloudflare_worker_script
cloudflare_worker_route
tiered_cache
NEW resource cloudflare_snippet which should be used in place of cloudflare_snippets. cloudflare_snippets is now deprecated. This enables the management of Cloudflare's snippet functionality through Terraform.
DNS Record Improvements: Enhanced handling of DNS record drift detection
Load Balancer Fixes: Resolved created_on field inconsistencies and improved pool configuration handling
Bot Management: Enhanced auto-update model state consistency and fight mode configurations
Other bug fixes
For a more detailed look at all of the changes, refer to the
changelog ↗ in GitHub.
If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new issue if one does not already exist for what you are experiencing.
Upgrading
We suggest holding off on migration to v5 while we work on stabilization. This help will you avoid any blocking issues while the Terraform resources are actively being stabilized.
If you'd like more information on migrating from v4 to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition. These do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test
your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.
We improved AI crawler management with detailed analytics and introduced custom HTTP 402 responses for blocked crawlers. AI Audit has been renamed to AI Crawl Control and is now generally available.
Enhanced Crawlers tab:
View total allowed and blocked requests for each AI crawler
Trend charts show crawler activity over your selected time range per crawler
Custom block responses (paid plans):
You can now return HTTP 402 "Payment Required" responses when blocking AI crawlers, enabling direct communication with crawler operators about licensing terms.
For users on paid plans, when blocking AI crawlers you can configure:
Response code: Choose between 403 Forbidden or 402 Payment Required
Response body: Add a custom message with your licensing contact information
Example 402 response:
HTTP 402 Payment RequiredDate: Mon, 24 Aug 2025 12:56:49 GMTContent-type: application/jsonServer: cloudflareCf-Ray: 967e8da599d0c3fa-EWRCf-Team: 2902f6db750000c3fa1e2ef400000001{ "message": "Please contact the site owner for access."}
Cloudflare Logpush can now deliver logs from using fixed, dedicated egress IPs. By routing Logpush traffic through a Cloudflare zone enabled with Aegis IP, your log destination only needs to allow Aegis IPs making setup more secure.
Highlights:
Fixed egress IPs ensure your destination only accepts traffic from known addresses.
Works with any supported Logpush destination.
Recommended to use a dedicated zone as a proxy for easier management.
To get started, work with your Cloudflare account team to provision Aegis IPs, then configure your Logpush job to deliver logs through the proxy zone. For full setup instructions, refer to the Logpush documentation.
Customers can now rely on Log Explorer to meet their log retention compliance requirements.
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.
Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare Community related to the v5 release. We have committed to releasing improvements on a two week cadence to ensure stability and reliability.
One key change we adopted in recent weeks is a pivot to more comprehensive, test-driven development. We are still evaluating individual issues, but are also investing in much deeper testing to drive our stabilization efforts. We will subsequently be investing in comprehensive migration scripts. As a result, you will see several of the highest traffic APIs have been stabilized in the most recent release, and are supported by comprehensive acceptance tests.
Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.
If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new one if one does not already exist for what you are experiencing.
Upgrading
We suggest holding off on migration to v5 while we work on stabilization. This will help you avoid any blocking issues while the Terraform resources are actively being stabilized.
If you'd like more information on migrating to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition. These migration scripts do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.
Cloudflare Logpush now supports IBM Cloud Logs as a native destination.
Logs from Cloudflare can be sent to IBM Cloud Logs ↗ via Logpush. The setup can be done through the Logpush UI in the Cloudflare Dashboard or by using the Logpush API. The integration requires IBM Cloud Logs HTTP Source Address and an IBM API Key. The feature also allows for filtering events and selecting specific log fields.
Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2 week cadeance to ensure it's stability and reliability. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach - we will be focusing on specific resources for every release, stabilizing the release and closing all associated bugs with that resource before moving onto resolving migration issues.
Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.
Changes
Resources stabilized:
cloudflare_custom_pages
cloudflare_page_rule
cloudflare_dns_record
cloudflare_argo_tiered_caching
Addressed chronic drift issues in cloudflare_logpush_job, cloudflare_zero_trust_dns_location, cloudflare_ruleset & cloudflare_api_token
cloudflare_zone_subscription returns expected values rate_plan.id from former versions
cloudflare_workers_script can now successfully be destroyed with bindings & migration for Durable Objects now recorded in tfstate
Ability to configure add_headers under cloudflare_zero_trust_gateway_policy
Other bug fixes
For a more detailed look at all of the changes, see the changelog ↗ in GitHub.
If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new one if one does not already exist for what you are experiencing.
Upgrading
We suggest holding off on migration to v5 while we work on stabilization. This help will you avoid any blocking issues while the Terraform resources are actively being stabilized.
If you'd like more information on migrating from v4 to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition, although these do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.
The Audit Logs v2 UI is now available to all Cloudflare customers in Beta. This release builds on the public Beta of the Audit Logs v2 API and introduces a redesigned user interface with powerful new capabilities to make it easier to investigate account activity.
Enabling the new UI
To try the new user interface, go to Manage Account > Audit Logs. The previous version of Audit Logs remains available and can be re-enabled at any time using the Switch back to old Audit Logs link in the banner at the top of the page.
New Features:
Advanced Filtering: Filter logs by actor, resource, method, and more for faster insights.
On-hover filter controls: Easily include or exclude values in queries by hovering over fields within a log entry.
Detailed Log Sidebar: View rich context for each log entry without leaving the main view.
JSON Log View: Inspect the raw log data in a structured JSON format.
Custom Time Ranges: Define your own time windows to view historical activity.
Infinite Scroll: Seamlessly browse logs without clicking through pages.
A small number of audit logs may currently be unavailable in Audit Logs v2. In some cases, certain fields such as actor information may be missing in certain audit logs. We are actively working to improve coverage and completeness for General Availability.
Export to CSV is not supported in the new UI.
We are actively refining the Audit Logs v2 experience and welcome your feedback. You can share overall feedback by clicking the thumbs up or thumbs down icons at the top of the page, or provide feedback on specific audit log entries using the thumbs icons next to each audit log line or by filling out our feedback form ↗.
Your real-time applications running over Cloudflare Tunnel are now faster and more reliable. We've completely re-architected the way cloudflared proxies UDP traffic in order to isolate it from other traffic, ensuring latency-sensitive applications like private DNS are no longer slowed down by heavy TCP traffic (like file transfers) on the same Tunnel.
This is a foundational improvement to Cloudflare Tunnel, delivered automatically to all customers. There are no settings to configure — your UDP traffic is already flowing faster and more reliably.
What’s new:
Faster UDP performance: We've significantly reduced the latency for establishing new UDP sessions, making applications like private DNS much more responsive.
Greater reliability for mixed traffic: UDP packets are no longer affected by heavy TCP traffic, preventing timeouts and connection drops for your real-time services.
Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare community related to the v5 release, with 13.5% of resources impacted. We have committed to releasing improvements on a 2 week cadeance to ensure it's stability and relability, including the v5.7 release.
Thank you for continuing to raise issues and please keep an eye on this changelog for more information about upcoming releases.
Changes
Addressed permanent diff bug on Cloudflare Tunnel config
State is now saved correctly for Zero Trust Access applications
Exact match is now working as expected within data.cloudflare_zero_trust_access_applications
cloudflare_zero_trust_access_policy now supports OIDC claims & diff issues resolved
Self hosted applications with private IPs no longer require a public domain for cloudflare_zero_trust_access_application.
New resource:
cloudflare_zero_trust_tunnel_warp_connector
Other bug fixes
For a more detailed look at all of the changes, see the
changelog ↗ in GitHub.
If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new one if one does not already exist for what you are experiencing.
Upgrading
We suggest holding on migration to v5 while we work on stabilization of the v5 provider. This will ensure Cloudflare can work ahead and avoid any blocking issues.
If you'd like more information on migrating from v4 to v5, please make use of the
migration guide ↗. We have
provided automated migration scripts using Grit which simplify the transition, although these do not support implementations which
use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test
your changes before applying, and let us know if you encounter any additional issues by reporting to our
GitHub repository ↗.
Log Explorer customers can now monitor their data ingestion volume to keep track of their billing. Monthly usage is displayed at the top of the Log Search and Manage Datasets screens in Log Explorer.
We are introducing a new feature of AI Crawl Control — Pay Per Crawl. Pay Per Crawl enables site owners to require payment from AI crawlers every time the crawlers access their content, thereby fostering a fairer Internet by enabling site owners to control and monetize how their content gets used by AI.
For Site Owners:
Set pricing and select which crawlers to charge for content access
Manage payments via Stripe
Monitor analytics on successful content deliveries
For AI Crawler Owners:
Use HTTP headers to request and accept pricing
Receive clear confirmations on charges for accessed content
We're announcing the GA of User Groups for Cloudflare Dashboard and System for Cross Domain Identity Management (SCIM) User Groups, strengthening our RBAC capabilities with stable, production-ready primitives for managing access at scale.
What's New
User Groups [GA]: User Groups are a new Cloudflare IAM primitive that enable administrators to create collections of account members that are treated equally from an access control perspective. User Groups can be assigned permission policies, with individual members in the group inheriting all permissions granted to the User Group. User Groups can be created manually or via our APIs.
SCIM User Groups [GA]: Centralize & simplify your user and group management at scale by syncing memberships directly from your upstream identity provider (like Okta or Entra ID) to the Cloudflare Platform. This ensures Cloudflare stays in sync with your identity provider, letting you apply Permission Policies to those synced groups directly within the Cloudflare Dashboard.
Stability & Scale:
These features have undergone extensive testing during the Public Beta period and are now ready for production use across enterprises of all sizes.
Log Explorer is now GA, providing native observability and forensics for traffic flowing through Cloudflare.
Search and analyze your logs, natively in the Cloudflare dashboard. These logs are also stored in Cloudflare's network, eliminating many of the costs associated with other log providers.
With Log Explorer, you can now:
Monitor security and performance issues with custom dashboards – use natural language to define charts for measuring response time, error rates, top statistics and more.
Investigate and troubleshoot issues with Log Search – use data type-aware search filters or custom sql to investigate detailed logs.
Save time and collaborate with saved queries – save Log Search queries for repeated use or sharing with other users in your account.
Access Log Explorer at the account and zone level – easily find Log Explorer at the account and zone level for querying any dataset.
Earlier this year, we announced the launch of the new Terraform v5 Provider.
Unlike the earlier Terraform providers, v5 is automatically generated based on the OpenAPI Schemas for our REST APIs. Since
launch, we have seen an unexpectedly high number of issues ↗
reported by customers. These issues currently impact about 15% of resources. We have been working diligently to address
these issues across the company, and have released the v5.6.0 release which includes a number of bug fixes. Please keep an
eye on this changelog for more information about upcoming releases.
Changes
Broad fixes across resources with recurring diffs, including, but not limited to:
cloudflare_zero_trust_access_identity_provider
cloudflare_zone
cloudflare_page_rules runtime panic when setting cache_level to cache_ttl_by_status
Failure to serialize requests in cloudflare_zero_trust_tunnel_cloudflared_config
Undocumented field 'priority' on zone_lockdown resource
Missing importability for cloudflare_zero_trust_device_default_profile_local_domain_fallback and cloudflare_account_subscription
New resources:
cloudflare_schema_validation_operation_settings
cloudflare_schema_validation_schemas
cloudflare_schema_validation_settings
cloudflare_zero_trust_device_settings
Other bug fixes
For a more detailed look at all of the changes, see the
changelog ↗ in GitHub.
If you have an unaddressed issue with the provider, we encourage you to check the
open issues ↗ and open a new one if one does not already
exist for what you are experiencing.
Upgrading
If you are evaluating a move from v4 to v5, please make use of the
migration guide ↗. We have
provided automated migration scripts using Grit which simplify the transition, although these do not support implementations which
use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test
your changes before applying, and let us know if you encounter any additional issues by reporting to our
GitHub repository ↗.
Custom Errors can now fetch and store assets and error pages from your origin even if they are served with a 4xx or 5xx HTTP status code — previously, only 200 OK responses were allowed.
What’s new:
You can now upload error pages and error assets that return error status codes (for example, 403, 500, 502, 503, 504) when fetched.
These assets are stored and minified at the edge, so they can be reused across multiple Custom Error rules without triggering requests to the origin.
This is especially useful for retrieving error content or downtime banners from your backend when you can’t override the origin status code.
You can now use the cf.worker.upstream_zone field in Transform Rules to control rule execution based on whether a request originates from Workers, including subrequests issued by Workers in other zones.
What's new:
cf.worker.upstream_zone is now supported in Transform Rules expressions.
