{"id":"src_qKL2i-lRM1l_QNMpdS1vU","slug":"cloudflare-application-performance","name":"Application Performance Changelog","type":"feed","url":"https://developers.cloudflare.com/changelog/?area=application-performance","orgId":"org_fW6EY8PY8Cr42ifo1IUAm","productId":"prod_BMN6dJIvkYpD6fJhmpXrp","productSlug":"application-performance","org":{"id":"org_fW6EY8PY8Cr42ifo1IUAm","slug":"cloudflare","name":"Cloudflare"},"isPrimary":false,"isHidden":false,"discovery":"curated","fetchPriority":"normal","metadata":"{\"feedUrl\":\"https://developers.cloudflare.com/changelog/rss/application-performance.xml\",\"feedType\":\"rss\",\"feedDiscoveredAt\":\"2026-06-19T21:04:40.976Z\",\"noFeedFound\":false,\"feedContentDepth\":\"full\",\"feedEtag\":\"\\\"9b050e701acf65bbcec77c90976bfec2\\\"\",\"feedContentLength\":\"319300\",\"enrichment\":{\"consecutiveFailures\":1},\"sourceActor\":{\"nextAlarmAt\":\"2026-11-03T12:56:58.329Z\",\"lastAlarmAt\":\"2026-11-03T09:00:30.431Z\",\"managed\":true}}","notice":null,"kind":null,"stars":null,"starsFetchedAt":null,"releaseCount":73,"releasesLast30Days":8,"avgReleasesPerWeek":1.5,"latestVersion":"1.3","latestDate":"2026-10-30T00:00:00.000Z","changelogUrl":null,"hasChangelogFile":false,"lastFetchedAt":"2026-10-30T19:47:22.756Z","lastPolledAt":"2026-11-03T09:00:28.319Z","changeDetectedAt":null,"trackingSince":"2024-02-26T00:00:00.000Z","releases":[{"id":"rel_eI19Ow07NdLQMSO95zZMU","version":"1.3","type":"feature","title":"SSL/TLS - Keyless SSL supports TLS 1.3 with ECDSA certificates","summary":"When TLS 1.3 is enabled on a zone, visitors connecting to a hostname that serves a Keyless ECDSA certificate now negotiate TLS 1.3 while private keys stay on the customer's own key server. Keyless SSL connections using RSA certificates continue to negotiate up to TLS 1.2.","titleGenerated":"Cloudflare Keyless SSL now supports TLS 1.3 with ECDSA certificates","titleShort":"Keyless SSL with ECDSA certs now negotiates TLS 1.3","breaking":"none","importance":3,"content":"[Keyless SSL](https://developers.cloudflare.com/ssl/keyless-ssl/) supports TLS 1.3 for ECDSA certificates. When [TLS 1.3](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/tls-13/) is enabled on your zone, visitors connecting to a hostname that serves a Keyless ECDSA certificate negotiate TLS 1.3, and your private keys stay on your own key server.\n\nKeyless SSL connections that use RSA certificates continue to negotiate up to TLS 1.2.\n\nFor details, refer to the [Keyless SSL limitations](https://developers.cloudflare.com/ssl/keyless-ssl/#limitations).","publishedAt":"2026-10-30T00:00:00.000Z","fetchedAt":"2026-10-30T19:47:15.328Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-30-keyless-ssl-tls13-ecdsa/","media":[],"coverageCount":0},{"id":"rel_ASXKf8qPU-erQY0znwpmT","version":null,"type":"feature","title":"DNS - New DNS records experience is now the default for everyone","summary":"The new DNS records experience is now the default on all plans including Enterprise, and the classic DNS records page is no longer available in the dashboard. Changing an existing record's type, such as A to CNAME, is now supported via the batch DNS records endpoint.","titleGenerated":"Cloudflare retires classic DNS records page for all users","titleShort":"Classic DNS records page retired; record type changes return","breaking":"major","importance":4,"content":"The new DNS records experience [announced in May](https://developers.cloudflare.com/changelog/post/2026-05-20-new-dns-records-ux/) is now the default for all users on all plans, including Enterprise. The classic DNS records page has been retired and is no longer available in the Cloudflare dashboard.\n\n#### Changing a record's type\n\nWhen the new experience first launched, it did not support changing the type of an existing DNS record. Based on your feedback, we have since added this, so you can now change a record's type (for example, from `A` to `CNAME`) directly from the DNS records page. Under the hood, the dashboard uses the [batch DNS records endpoint](https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/batch/) for this.\n\n#### Questions or feedback\n\nIf you run into an issue with the new experience, contact your account team or [Cloudflare Support](https://developers.cloudflare.com/support/contacting-cloudflare-support/).","publishedAt":"2026-10-30T00:00:00.000Z","fetchedAt":"2026-10-30T15:43:47.292Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-30-classic-dns-records-page-retired/","media":[],"coverageCount":0},{"id":"rel_h43QLJMQcWCg09Q9PYnKS","version":null,"type":"feature","title":"Data Localization Suite, SSL/TLS - View your data localization settings in one dashboard page","summary":"A read-only Data Localization Suite overview in the Cloudflare dashboard consolidates Regional Services, Customer Metadata Boundary, and Geo Key Manager settings, with tabs per product and links to the page where each setting is changed.","titleGenerated":"Cloudflare adds read-only Data Localization Suite overview dashboard","titleShort":"Data Localization Suite settings now in one dashboard page","breaking":"none","importance":2,"content":"The Cloudflare dashboard now includes a **Data Localization Suite** Overview, a read-only view of the data localization settings on your account. It shows your Regional Services, Customer Metadata Boundary, and Geo Key Manager settings in one place, so you no longer need to check several dashboard pages and APIs to see where your traffic is processed and where your logs and private keys are stored.\n\nTo find it, go to **Application Security** > **Data Localization Suite**, or search for \"DLS\" in the dashboard.\n\nThe Overview has a tab for each product:\n\n- **Regional Services**: regionalized hostnames (filter by region or zone), regionalized IP bindings, and regionalized Spectrum applications, each with its region.\n- **Customer Metadata Boundary**: whether the boundary is on, the region (US or EU), and whether out-of-region access is allowed.\n- **Geo Key Manager**: every custom certificate with a geo policy, with its hostname, zone, region, and status.\n\nEach item links to the dashboard page where you change its setting, and each tab links to the product's documentation.\n\nTo learn more, refer to the [Data Localization Suite documentation](https://developers.cloudflare.com/data-localization/).","publishedAt":"2026-10-29T00:00:00.000Z","fetchedAt":"2026-10-30T19:47:15.328Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-29-dls-dashboard-overview/","media":[],"coverageCount":0},{"id":"rel_ur-T5hdTd2adxFHwxUBvy","version":null,"type":"feature","title":"China Network, Challenges, Bots - China-native Challenge Pages for the China Network","summary":"Challenge Pages on the Cloudflare China Network now use Turnstile widgets hosted in Mainland China, so visitors there complete challenges faster without cross-border requests. The change applies automatically to China Network zones, while the global network keeps its existing Challenge Page experience.","titleGenerated":"Cloudflare China Network serves Challenge Pages with China-hosted Turnstile","titleShort":"China Network challenges now served locally; no cross-border requests","breaking":"none","importance":3,"content":"Challenge Pages served through the Cloudflare China Network now use Turnstile widgets hosted in Mainland China. This means that visitors in Mainland China can complete challenges faster and more reliably because widgets no longer need to make cross-border requests.\n\n**You do not need to take any action: this change applies automatically when a China Network zone presents a Challenge Page.** Visitors served by Cloudflare's global network will continue to receive the global Challenge Page experience.\n\nFor more information, refer to [Interstitial Challenge Pages](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/) and [Cloudflare China Network](https://developers.cloudflare.com/china-network/).","publishedAt":"2026-10-28T00:00:00.000Z","fetchedAt":"2026-10-28T23:08:54.413Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-28-china-native-challenge-pages/","media":[],"coverageCount":0},{"id":"rel_D0deKSsKwNMNz8aYBByfH","version":null,"type":"feature","title":"DNS - Advanced Nameservers use a nameserver type","summary":"DNS settings endpoints for zones and account defaults gradually represent Advanced Nameservers with nameservers.type: \"cloudflare.advanced\", replacing the foundation_dns: true configuration over a seven-day rollout. foundation_dns remains as a deprecated compatibility alias and will be removed in a future API change, and PATCH requests containing both values are rejected if they conflict.","titleGenerated":"Cloudflare DNS settings now represent Advanced Nameservers via nameservers.type","titleShort":"Advanced Nameservers use nameservers.type; foundation_dns deprecated","breaking":"minor","importance":3,"content":"Starting today, the [DNS settings endpoints](https://developers.cloudflare.com/api/resources/dns/subresources/settings/) gradually begin to represent Advanced Nameservers with `nameservers.type: \"cloudflare.advanced\"`. The rollout is expected to take seven days. Previously, the API used the `\"foundation_dns\": true` setting for this configuration.\n\nBefore the rollout reaches an account, the endpoints continue to return `nameservers.type: \"cloudflare.standard\"` for Advanced Nameservers. The endpoints accept `nameservers.type: \"cloudflare.advanced\"` in `PATCH` requests for entitled accounts throughout the rollout. The zone settings JSON for [`/zones/{zone_id}/dns_settings`](https://developers.cloudflare.com/api/resources/dns/subresources/settings/subresources/zone/) is:\n\n```\n{\n \"nameservers\": {\n \"type\": \"cloudflare.advanced\"\n },\n \"foundation_dns\": true\n}\n```\n\nCloudflare will make an equivalent change to [`/accounts/{account_id}/dns_settings`](https://developers.cloudflare.com/api/resources/dns/subresources/settings/subresources/account/) at the same time.\n\nThe `foundation_dns` boolean remains available as a deprecated compatibility alias in zone and account-default settings. Use `nameservers.type: \"cloudflare.advanced\"` for new writes.\n\nYou can continue to read and write `foundation_dns` during this transition. If a `PATCH` request includes both values, they must match. The API rejects conflicting values.\n\nUpdate clients that treat `nameservers.type` as a closed enum to recognize the `\"cloudflare.advanced\"` value.\n\nThis API update does not change your Foundation DNS subscription or whether Advanced Nameservers are enabled on your zones. It does not require a zone migration.\n\nIn a future API change, Cloudflare will remove the `foundation_dns` parameter from the API endpoint. After migrating to `nameservers.type`, remove handling for the boolean from your client.","publishedAt":"2026-10-26T00:00:00.000Z","fetchedAt":"2026-10-26T10:16:33.853Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-26-foundation-dns-nameserver-type/","media":[],"coverageCount":0},{"id":"rel_0lHF_6x4xRRnXS9X8AJ0k","version":null,"type":"feature","title":"DNS - Configure Advanced Custom Nameservers with nameserver sets (beta)","summary":"Nameserver sets are now in beta for Enterprise accounts, grouping two to five custom nameserver names with Cloudflare-assigned IP addresses that can be assigned to zones in the same account. Setting advanced to true allocates addresses from Advanced anycast network groups, and sets are immutable reusable objects that lift the legacy limit of 5 numbered sets; legacy custom_ns sets remain supported alongside them.","titleGenerated":"Cloudflare DNS launches beta nameserver sets for Advanced Custom Nameservers","titleShort":"Nameserver sets beta for Advanced Custom Nameservers","breaking":"none","importance":3,"content":"[Nameserver sets](https://developers.cloudflare.com/dns/nameservers/custom-nameservers/nameserver-sets/) are now available in beta to Enterprise accounts. A nameserver set groups two to five custom nameserver names with Cloudflare-assigned IP addresses. You can assign the set to zones in the same account.\n\nEnterprise customers using Cloudflare DNS can create Advanced Custom Nameserver sets. These sets distribute addresses across Advanced anycast network groups to improve resiliency.\n\nCompared to legacy `custom_ns` sets, modern nameserver sets offer several advantages:\n\n- **Sets are reusable objects.** Accounts are no longer limited to 5 numbered sets. Create a set once and assign it to one or more zones in the same account.\n- **Custom address counts.** Assign each nameserver up to 3 IPv4 and 3 IPv6 addresses. This allows for more flexible setups.\n- **Diverse addresses.** IPv4 and IPv6 addresses are now both selected from a diverse set of prefixes for increased redundancy.\n- **Support for Advanced Custom Nameservers.** Set `advanced` to `true` to allocate addresses from Advanced anycast network groups, providing the same benefits as Cloudflare branded [Advanced nameservers](https://developers.cloudflare.com/dns/foundation-dns/advanced-nameservers/) to your custom nameservers.\n- **Explicit changes.** Sets are immutable, so adding or removing a nameserver name never changes the configuration of zones that already use a set.\n\nCreate a set by sending a `POST` request to `/accounts/{account_id}/dns_settings/nameserver_sets` with the following body:\n\n```\n{\n\t\"advanced\": true,\n\t\"ip_set\": 1,\n\t\"nameservers\": [\n\t\t{ \"name\": \"ns1.example.com\" },\n\t\t{ \"name\": \"ns2.example.com\" },\n\t\t{ \"name\": \"ns3.example.com\" }\n\t]\n}\n```\n\nThen, send a `PATCH` request to `/zones/{zone_id}/dns_settings` with the returned nameserver set ID:\n\n```\n{\n\t\"nameservers\": {\n\t\t\"type\": \"custom\",\n\t\t\"nameserver_set_id\": \"0123456789abcdef0123456789abcdef\"\n\t}\n}\n```\n\nThis configures the zone to use the nameserver set.\n\nFor more information, including other setup steps, refer to [Nameserver sets](https://developers.cloudflare.com/dns/nameservers/custom-nameservers/nameserver-sets/).\n\nLegacy `custom_ns` sets remain supported. A single account can use both.","publishedAt":"2026-10-14T00:00:00.000Z","fetchedAt":"2026-10-14T14:12:15.700Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-14-nameserver-sets/","media":[],"coverageCount":0},{"id":"rel_u5fa1Rud8xNINisHfWtLv","version":null,"type":"feature","title":"Cloudflare Web Analytics - Deeper Core Web Vitals Diagnostics: LCP & INP Sub-Part Metrics in Real User Monitoring","summary":"Real User Monitoring in Web Analytics now breaks Largest Contentful Paint into four phases and Interaction to Next Paint into three, and splits connection time into TCP and TLS handshake. The sub-parts are shown in the dashboard and queryable through the GraphQL Analytics API via fields like lcpResourceLoadDelayP50 and inpInputDelayP50 on rumWebVitalsEventsAdaptiveGroups.","titleGenerated":"Cloudflare Web Analytics breaks LCP and INP into sub-part metrics","titleShort":"LCP and INP split into sub-part metrics","breaking":"none","importance":3,"content":"The Core Web Vitals tell you whether a page is slow but beyond perceived load time, layout instability or responsiveness they don't guide you to the problematic area directly. To help you with this, Real User Monitoring (RUM) in Web Analytics now breaks Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) into their respective sub-parts. It also splits connection time into TCP and TLS. You can see this visualised in the dashboard or query it through the GraphQL Analytics API.\n\n#### LCP sub-parts\n\nLCP is broken into four phases, so you can see which one is impacting your perceived load time:\n\n1. **Time to First Byte:** how long the browser waits for the HTML document (`timeToFirstByte` in GraphQL).\n2. **Resource load delay:** how long the browser takes to discover the LCP resource after the document starts arriving (`lcpResourceLoadDelay`).\n3. **Resource load duration:** how long it takes to download that resource (`lcpResourceLoadTime`).\n4. **Element render delay:** the gap between the resource arriving and the element appearing on screen (`lcpElementRenderDelay`).\n\nYou don't have to remember all this detail, there are tooltips available to guide you next to each sub-part metric in the dashboard.\n\n\n\n#### INP sub-parts\n\nINP is broken into three phases, guiding you to the area slowing down responsiveness:\n\n1. **Input delay:** how long an interaction (click, tap or key press) is blocked before it can be processed (`inpInputDelay`).\n2. **Processing duration:** how long your event handlers take to run (`inpProcessingDuration`).\n3. **Presentation delay:** how long the browser takes to render the next frame after the handlers finish (`inpPresentationDelay`).\n\n\n\n#### TCP and TLS timing\n\nThe page load timing breakdown now separates connection setup from the TLS handshake, so you can tell a slow network path from a slow TLS negotiation:\n\n- **Connection time (excluding TLS)** (`connectionTimeWithoutTLS`)\n- **TLS handshake time:** (`tlsTime`).\n\nNote: we've retained `connectionTime` in the GraphQL API so you can still analyze the combined time.\n\n#### Querying the GraphQL data\n\nThe sub-parts are available on `rumWebVitalsEventsAdaptiveGroups` as percentiles, for example: `lcpResourceLoadDelayP50` or `inpInputDelayP50`. The connection split is available on `rumPerformanceEventsAdaptiveGroups` as `connectionTimeWithoutTLSP50` and `tlsTimeP50`, and so on for the other percentiles.\n\nThe percentiles available are: P25, P50, P75, P90, P95, P99, P999. All values are in microseconds. A negative value means the data isn't available.\n\nTo get started, open [Web Analytics in the dashboard ↗︎](https://dash.cloudflare.com/?to=/:account/web-analytics/sites), select your site and navigate to the Core Web Vitals section. For more on the data, refer to [the Web Analytics docs ↗︎](https://developers.cloudflare.com/web-analytics/) and [the GraphQL Analytics API docs ↗︎](https://developers.cloudflare.com/analytics/graphql-api/).","publishedAt":"2026-10-13T00:00:00.000Z","fetchedAt":"2026-10-13T13:51:20.956Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-13-core-web-vital-subparts/","media":[{"type":"image","url":"https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=1704,height=384,format=webp/_astro/dash-web_analytics-lcp-sub-parts.CSpKXT00.png","alt":"LCP sub-parts visual in the dashboard","r2Key":"releases/f967a702724e21f4ad65ed24fdccfc79b38756836135bfac5db35de90e88855a.png","r2Url":"https://media.releases.sh/releases/f967a702724e21f4ad65ed24fdccfc79b38756836135bfac5db35de90e88855a.png"},{"type":"image","url":"https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=1704,height=382,format=webp/_astro/dash-web_analytics-inp-sub-parts.DWKDfc7K.png","alt":"INP sub-parts visual in the dashboard","r2Key":"releases/91efdcc9d1eb06f18f402470ead194d48c3540e0927aca60fbad4f0b9d444cc5.png","r2Url":"https://media.releases.sh/releases/91efdcc9d1eb06f18f402470ead194d48c3540e0927aca60fbad4f0b9d444cc5.png"}],"coverageCount":0},{"id":"rel_cE6OXX8YIgBkp7elypIWo","version":null,"type":"feature","title":"DNS - Warnings when approaching your DNS records quota","summary":"The DNS records page in the Cloudflare dashboard now shows a warning once 85% of a DNS records quota is used. The warning reflects the applicable quota, showing per-zone usage for zones with their own quota and account-wide usage for accounts using an account-level DNS records quota.","titleGenerated":"Cloudflare DNS records page warns at 85% of quota","titleShort":"DNS records page warns at 85% of quota","breaking":"none","importance":2,"content":"The DNS records page in the Cloudflare dashboard now shows a warning once you have used 85% of your [DNS records quota](https://developers.cloudflare.com/dns/manage-dns-records/#dns-records-quota).\n\nThe warning reflects the quota that applies to you. If your zone has its own quota, the warning shows that zone's usage. If your account uses an [account-level DNS records quota](https://developers.cloudflare.com/dns/manage-dns-records/#per-account-quota), the warning shows your usage across all zones in the account.\n\n","publishedAt":"2026-10-06T00:00:00.000Z","fetchedAt":"2026-10-06T15:28:32.467Z","url":"https://developers.cloudflare.com/changelog/post/2026-10-06-dns-records-quota-warning/","media":[{"type":"image","url":"https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=1520,height=226,format=webp/_astro/dns-records-quota-warning.iH_msM4_.png","alt":"Warning on the DNS records page showing that a domain has used 86% of its DNS record limit","r2Key":"releases/a736a607ab2f6fd26d4e6e41e5b04cb11f26d820837b43646bbdb6ae9ef2e3a2.png","r2Url":"https://media.releases.sh/releases/a736a607ab2f6fd26d4e6e41e5b04cb11f26d820837b43646bbdb6ae9ef2e3a2.png"}],"coverageCount":0},{"id":"rel_uZcOzN5ZPdsUSSJ1SqUlw","version":null,"type":"feature","title":"Cache - Purge now forces a cache miss for Cache Reserve content","summary":"Purge requests by tag, hostname, prefix, or everything now force a Cache Reserve miss instead of marking matching content for revalidation, so the origin must redeliver content in full and Cloudflare rewrites it as a billed Class A operation; purging by URL is unchanged. A new invalidate_cache endpoint preserves the previous revalidation behavior and can serve stale content during revalidation.","titleGenerated":"Cloudflare purge now forces cache miss for Cache Reserve content","titleShort":"Purge now forces Cache Reserve miss; new invalidate_cache endpoint","breaking":"major","importance":4,"content":"Purge requests now force a cache miss for [Cache Reserve](https://developers.cloudflare.com/cache/advanced-configuration/cache-reserve/) content, regardless of purge type. Previously, purging by cache tag, hostname, prefix, or everything marked matching Cache Reserve content for revalidation. Purging by URL already removed content from Cache Reserve and is unchanged.\n\nThis change applies to purge requests from the API and the dashboard. Cache Reserve now handles purges the same way as the edge cache.\n\n#### Cost impact\n\nAfter a purge, the next request for affected content is a Cache Reserve miss. Your origin must deliver the content in full, even if it has not changed. Cloudflare then writes the content to Cache Reserve again, which is billed as a [Class A operation](https://developers.cloudflare.com/cache/advanced-configuration/cache-reserve/#pricing).\n\nPurging by tag, hostname, prefix, or everything does not delete content from Cache Reserve right away. Matching content continues to incur storage costs until a later request replaces it or its retention period ends.\n\nIf you frequently purge Cache Reserve content by tag, hostname, prefix, or everything, review the effect on your origin egress and Cache Reserve usage.\n\n#### Keep revalidating Cache Reserve content\n\nTo keep content in Cache Reserve and revalidate it instead, send the same request to the new `invalidate_cache` endpoint:\n\n```\ncurl --request POST \\\n \"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache\" \\\n --header \"Authorization: Bearer $CLOUDFLARE_API_TOKEN\" \\\n --header \"Content-Type: application/json\" \\\n --data '{\"tags\":[\"product-images\"]}'\n```\n\nIn the dashboard, use **Invalidate Cache** on the **Caching** > **Configuration** page.\n\nIf your origin responds with `304 Not Modified`, Cloudflare reuses the stored content instead of fetching it from your origin again. Compared with purging, invalidation reduces origin egress but not Cache Reserve operations. Updating the stored content after a `304` response is still a Class A operation. Invalidating by URL also updates the stored content when you send the request, which is a Class A operation.\n\nUnlike the previous purge behavior, invalidation can serve stale content while it revalidates if your cache settings allow it. This applies only to copies in the edge cache, not to content served from Cache Reserve. Cloudflare can also serve invalidated content stale if your origin returns a `5xx` error or cannot be reached. For details, refer to [Invalidate cached content](https://developers.cloudflare.com/cache/guides/invalidate-cache/#stale-content-during-revalidation).","publishedAt":"2026-09-28T00:00:00.000Z","fetchedAt":"2026-09-29T04:55:11.218Z","url":"https://developers.cloudflare.com/changelog/post/2026-09-28-cache-reserve-purge-behavior/","media":[],"coverageCount":0},{"id":"rel_2DsfrjHbdN6DHfeMFshbA","version":null,"type":"feature","title":"Cache - Invalidate cached content instead of purging it","summary":"A new invalidate_cache endpoint marks matching content as stale so Cloudflare revalidates with your origin on the next request and reuses the cached copy on a 304 Not Modified response. It supports the same selectors as purge and requires your origin to return an ETag or Last-Modified header and support conditional requests.","titleGenerated":"Cloudflare Application Performance adds cache invalidation endpoint","titleShort":"Invalidate cached content instead of purging it","breaking":"none","importance":3,"content":"You can now invalidate cached content instead of purging it. Invalidation marks matching content as stale. On the next request, Cloudflare revalidates the content with your origin. If your origin responds with `304 Not Modified`, Cloudflare reuses the cached content instead of downloading it again.\n\nUse invalidation to refresh a group of assets when only some of them have changed. For example, invalidate all content that shares a cache tag. Cloudflare reuses unchanged assets instead of downloading them again. This requires your origin to return an `ETag` or `Last-Modified` header and support conditional requests.\n\nInvalidation supports the same selectors as purge: URLs, cache tags, hostnames, URL prefixes, and everything. To invalidate content, send a `POST` request to the new `invalidate_cache` endpoint:\n\n```\ncurl --request POST \\\n \"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache\" \\\n --header \"Authorization: Bearer $CLOUDFLARE_API_TOKEN\" \\\n --header \"Content-Type: application/json\" \\\n --data '{\"tags\":[\"product-images\"]}'\n```\n\nIn the dashboard, use **Invalidate Cache** on the **Caching** > **Configuration** page.\n\nYour cache settings determine whether Cloudflare serves stale content while it revalidates. Cloudflare can also serve invalidated content stale if your origin returns a `5xx` error or cannot be reached. To stop serving cached content, purge it instead.\n\nInvalidation requests count toward the same [rate limits](https://developers.cloudflare.com/cache/guides/invalidate-cache/#limits) as purge requests.\n\nPurge behavior for Cache Reserve also changes with this release. For details, refer to [Cache Reserve purge behavior](https://developers.cloudflare.com/cache/advanced-configuration/cache-reserve/#purge-behavior).\n\nFor more information, refer to [Invalidate cached content](https://developers.cloudflare.com/cache/guides/invalidate-cache/).","publishedAt":"2026-09-28T00:00:00.000Z","fetchedAt":"2026-09-29T04:55:11.218Z","url":"https://developers.cloudflare.com/changelog/post/2026-09-28-cache-invalidation/","media":[],"coverageCount":0},{"id":"rel_9pDp7Fd2ap_0CNKoa9uj8","version":null,"type":"feature","title":"DNS - Shadowed record warnings are now available for all zones","summary":"Cloudflare now displays warnings for shadowed DNS records in all zones, flagging records that remain present but no longer resolve because a subdomain delegation gave another set of nameservers authority over the name. Shadow metadata is also returned in DNS records API responses when include_shadow_metadata=true, identifying the delegating NS records and whether an A or AAAA record is glue.","titleGenerated":"Cloudflare surfaces shadowed DNS record warnings for all zones","titleShort":"Shadowed DNS record warnings for all zones; API exposes metadata","breaking":"none","importance":3,"content":"Cloudflare now displays warnings for shadowed records in all zones. A record is shadowed when a subdomain delegation gives authority for its name, or a name below it, to another set of nameservers. The record remains present, but your zone is not authoritative for it thus Cloudflare will not respond with it to matching DNS queries. These warnings help you find records that may no longer resolve from the expected zone.\n\nShadow metadata is also available in DNS records API responses when you set `include_shadow_metadata=true`. The metadata identifies the delegating `NS` records and, when applicable, whether an `A` or `AAAA` record is glue. For more information, refer to [Shadowed records](https://developers.cloudflare.com/dns/manage-dns-records/reference/shadowed-records/).","publishedAt":"2026-09-14T00:00:00.000Z","fetchedAt":"2026-09-15T20:19:28.937Z","url":"https://developers.cloudflare.com/changelog/post/2026-09-14-shadowed-record-warnings/","media":[],"coverageCount":0},{"id":"rel_AU0eY2wKooqHoRKBnu3s-","version":null,"type":"feature","title":"Cache - Configure Origin Range Requests with the Rulesets API","summary":"The Rulesets API now supports Origin Range Requests in Cache Rules, letting Cloudflare fetch large files from origin in cache-aligned byte ranges via origin_range_requests.mode set to on, off, or default for matched traffic. Setting mode to off overrides Cloudflare's default generated range requests without changing cache eligibility.","titleGenerated":"Cloudflare Application Performance adds Origin Range Requests to Cache Rules via Rulesets API","titleShort":"Rulesets API gains Origin Range Requests for Cache Rules","breaking":"none","importance":3,"content":"The Rulesets API now supports Origin Range Requests in Cache Rules. This setting lets Cloudflare fetch large files from your origin in cache-aligned byte ranges. Cloudflare may expand a client range and issue several single-range origin requests.\n\nSet `origin_range_requests.mode` to `on`, `off`, or `default` for any traffic matched by a Cache Rule.\n\nTo override Cloudflare's default Origin Range Requests behavior, set the mode to `off`. The following rule turns off generated origin range requests for all traffic without changing cache eligibility:\n\n```\n{\n \"expression\": \"true\",\n \"action\": \"set_cache_settings\",\n \"action_parameters\": {\n \"origin_range_requests\": {\n \"mode\": \"off\"\n }\n }\n}\n```\n\nOrigin Range Requests do not make otherwise ineligible content cacheable. If your origin ignores `Range` and returns a complete `200 OK`, Cloudflare can use the response but must download the complete file. Origins should honor `Accept-Encoding: identity` and return consistent, unencoded partial responses.\n\nFor configuration details and mode behavior, refer to [Origin Range Requests in Cache Rules](https://developers.cloudflare.com/cache/how-to/cache-rules/settings/#origin-range-requests). For client responses and the complete origin contract, refer to [Range request behavior](https://developers.cloudflare.com/cache/reference/range-requests/).","publishedAt":"2026-09-02T00:00:00.000Z","fetchedAt":"2026-09-14T19:58:32.901Z","url":"https://developers.cloudflare.com/changelog/post/2026-09-02-origin-range-requests-rulesets-api/","media":[],"coverageCount":0},{"id":"rel_x3s0X4qNnCl8fIVzg8d4y","version":null,"type":"feature","title":"Load Balancing - Load Balancing now supports pool sets","summary":"Load Balancing now supports pool sets through the API, letting one load balancer apply different routing behavior per data center, country, or region — each pool set supplies its own candidate pools, steering policy, pool weights, and fallback pool, evaluated in array order. Pool sets support active-active distribution, location-specific failover, regional routing policies, and fixed HTTP responses for proxied traffic.","titleGenerated":"Cloudflare Load Balancing adds pool sets for location-specific traffic steering","titleShort":"Load Balancing pool sets enable location-specific steering","breaking":"none","importance":4,"content":"Cloudflare Load Balancing now supports pool sets through the API. Pool sets combine geographic matching with location-specific traffic steering. One load balancer can now use different routing behavior for different locations.\n\nEach pool set can match a Cloudflare data center, country, or region. It then supplies the candidate pools and can apply its own steering policy, pool weights, and fallback pool. Cloudflare evaluates pool sets in array order and applies the first matching pool set.\n\nFor example, this pool set uses Dynamic Latency steering for traffic from Germany:\n\n```\n{\n\t\"pool_sets\": [\n\t\t{\n\t\t\t\"name\": \"germany-lowest-latency\",\n\t\t\t\"match\": { \"topology\": { \"countries\": [\"DE\"] } },\n\t\t\t\"overrides\": {\n\t\t\t\t\"pools\": [\n\t\t\t\t\t\"0930eec54a4c7ae6616985b79f678210\",\n\t\t\t\t\t\"c8b4f5a6d7e84910a2b3c4d5e6f70819\"\n\t\t\t\t],\n\t\t\t\t\"steering_policy\": \"dynamic_latency\"\n\t\t\t}\n\t\t}\n\t]\n}\n```\n\nUse pool sets for active-active traffic distribution, location-specific failover, and regional routing policies. For proxied traffic, a pool set can also return a fixed HTTP response instead of selecting a pool.\n\nFor configuration details and more examples, refer to [Pool sets](https://developers.cloudflare.com/load-balancing/understand-basics/traffic-steering/pool-sets/).","publishedAt":"2026-08-31T00:00:00.000Z","fetchedAt":"2026-09-10T10:27:47.808Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-31-pool-sets/","media":[],"coverageCount":0},{"id":"rel_4wwGTOENII2PBzOb0Hna8","version":null,"type":"feature","title":"Load Balancing - Load Balancing now supports regional health","summary":"Each Cloudflare region can now make an independent health decision for a pool, so traffic can avoid an unreachable pool in one region without removing it from service elsewhere. Regional health is configured with the health_sources field on a pool; setting it to [\"regional\", \"global\"] prefers regional health and falls back to global, and pools without health_sources retain their existing behavior.","titleGenerated":"Cloudflare Load Balancing adds regional health decisions per pool","titleShort":"Load Balancing gets per-region health decisions","breaking":"none","importance":3,"content":"Cloudflare Load Balancing now supports regional health. Each Cloudflare region can make an independent health decision for a pool. When pool reachability differs by region, traffic can avoid an unreachable pool without removing it from service elsewhere.\n\nConfigure regional health with the `health_sources` field on a pool. Set it to `[\"regional\", \"global\"]` to prefer regional health and use global health when no regional decision is available. Pools without `health_sources` retain their existing health behavior.\n\nRegional health is useful for multi-region deployments and failures that affect specific network paths.\n\nFor more information, refer to [Regional health](https://developers.cloudflare.com/load-balancing/understand-basics/regional-health/).","publishedAt":"2026-08-28T00:00:00.000Z","fetchedAt":"2026-10-27T14:41:03.820Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-28-regional-health/","media":[],"coverageCount":0},{"id":"rel_Kce0-3VOXSzXdyv5GbHPE","version":null,"type":"feature","title":"Automatic Platform Optimization - APO caches more crawler and bot traffic again","summary":"Fixed a regression where Automatic Platform Optimization stopped caching HTML requests without an explicit Accept: text/html header, serving crawlers, bots, and uptime monitors from origin with cf-cache-status: DYNAMIC. No action is needed, and a Transform Rule setting Accept: text/html as a workaround can be removed.","titleGenerated":"Cloudflare APO caches crawler and bot traffic again after Accept-header regression","titleShort":"APO caches crawler and bot traffic again","breaking":"none","importance":3,"content":"We fixed a regression where Automatic Platform Optimization (APO) stopped caching some HTML requests that did not send an explicit `Accept: text/html` header — commonly crawlers, bots, and uptime monitors. These requests were being served from your origin (`cf-cache-status: DYNAMIC`) instead of the cache.\n\nAPO now caches these requests again. No action is needed. If you added a Transform Rule to set `Accept: text/html` as a workaround, you can remove it.\n\nFor details on how APO decides what to cache, refer to [About APO](https://developers.cloudflare.com/automatic-platform-optimization/about/).","publishedAt":"2026-08-27T00:00:00.000Z","fetchedAt":"2026-09-16T20:40:27.035Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-27-accept-header-caching/","media":[],"coverageCount":0},{"id":"rel_WK1XNrSDRBTreFdRV8oKM","version":null,"type":"feature","title":"Cloudflare Web Analytics - Web Analytics improves soft navigation measurement for Single Page Applications (SPAs)","summary":"Web Analytics now measures client-side soft navigations, adding two new navigationType values (`soft-navigation` and `routing-apis`) alongside the existing `navigate` bucket. Pageview volume reported in the dashboard and GraphQL API may change, and soft navigation LCP is now measured where Chrome's Soft Navigation API is available.","titleGenerated":"Application Performance Web Analytics improves soft navigation measurement for SPAs","titleShort":"SPA pageviews reclassified with new navigationType segments","breaking":"major","importance":3,"content":"Cloudflare Web Analytics (Real User Monitoring) is rolling out accuracy improvements to client-side soft navigations.\n\n**This change may alter the volume of pageviews reported in the dashboard and GraphQL API**, though the extent depends on your front-end architecture and visitor traffic patterns.\n\nSingle Page Applications (SPAs)—such as websites built with React, Angular, Vue, or Svelte—predominantly use soft navigations. Soft navigations avoid fully unloading the current page and rendering the next one from scratch as visitors navigate.\n\nAny client-side navigation counts as a soft navigation, including navigations intercepted by [the Navigation API ↗](https://developer.mozilla.org/en-US/docs/Web/API/Navigation_API) or triggered by [the History API ↗](https://developer.mozilla.org/en-US/docs/Web/API/History_API). This means a non-SPA website can have soft navigation activity if its implementation uses these APIs.\n\nThe main improvement comes from [Google Chrome's new Soft Navigation API ↗](https://developer.chrome.com/docs/web-platform/soft-navigations). It natively measures [Largest Contentful Paint (LCP)](https://developers.cloudflare.com/web-analytics/data-metrics/core-web-vitals/#core-web-vitals-metrics) on soft navigations, removing a blind spot in perceived loading speed across pageviews.\n\nWe've extended our `navigationType` values to segment these different types of navigations:\n\n`navigationType`\n\nNew?\n\nDescription\n\n`navigate`\n\n❌\n\nHard navigations that traditional websites (or \"Multi Page Applications\") perform when clicking links or submitting forms\n\n`soft-navigation`\n\n✅\n\nWhere [the new Soft Navigation API ↗](https://developer.chrome.com/docs/web-platform/soft-navigations) is available and a visitor makes a client-side navigation, we record these events\n\n`routing-apis`\n\n✅\n\nWhere the native Soft Navigation API is unavailable (e.g. Safari, Firefox, older Chromium-based browsers), we fallback to measuring soft navigations using [the Navigation API ↗](https://developer.mozilla.org/en-US/docs/Web/API/Navigation_API) or [History API ↗](https://developer.mozilla.org/en-US/docs/Web/API/History_API). We cannot collect LCP for these, but the other Core Web Vitals are present.\n\nPrior to this change, we only used History API and all navigations were bucketed into `navigate`.\n\nFor more information, refer to the [Navigation Types](https://developers.cloudflare.com/web-analytics/data-metrics/dimensions/#navigation-types) and [Web Analytics SPA](https://developers.cloudflare.com/web-analytics/get-started/web-analytics-spa/) documentation pages.","publishedAt":"2026-08-21T00:00:00.000Z","fetchedAt":"2026-08-21T19:42:49.356Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-21-improved-soft-navigation-measurement-for-single-page-applications/","media":[],"coverageCount":0},{"id":"rel_AKj8C52FQkXyCg_vpBuNE","version":null,"type":"feature","title":"Load Balancing - Load balancing analytics now filters by pool name","summary":"Load balancing analytics now filters traffic data by pool name instead of internal pool ID, matching the names in the dropdown and fixing filtering when pools share similar names. The change affects requests over time, pool distribution, top endpoints, and latency views; the Logs view and health event filtering are unchanged.","titleGenerated":"Cloudflare Application Performance Load Balancing analytics filter now uses pool names","titleShort":"Load balancing analytics filter now uses pool names","breaking":"none","importance":2,"content":"Load balancing analytics now filters traffic data by pool name instead of pool ID, aligning the query behavior with the pool names displayed in the filter dropdown.\n\nPreviously, the analytics pool filter queried by internal pool ID while displaying pool names in the UI dropdown. This mismatch caused filtering issues when pools shared similar names or when you expected results based on the visible pool name. Because the underlying query used a different identifier than what appeared on screen, the displayed data could be confusing or incorrect.\n\nThe pool filter now queries by the same pool name shown in the dropdown. When you select a pool from the filter, the analytics graphs and tables display data for that specific pool as you would expect. This change affects:\n\n- **Requests over time**, filtering the chart series to the selected pool.\n- **Pool distribution**, showing only the selected pool segment.\n- **Top endpoints**, displaying cards for origins in the selected pool.\n- **Latency**, showing latency data for the selected pool.\n\nThe **Logs** view and health event filtering are unchanged.\n\nTo use this, go to **Traffic** > **Load Balancing Analytics** for a zone. The same pool filter appears in the analytics view for an individual load balancer under **Load Balancing** at the account level.\n\nFor more information about analytics filters and metrics, refer to [Load Balancing Analytics](https://developers.cloudflare.com/load-balancing/reference/load-balancing-analytics/).","publishedAt":"2026-08-17T00:00:00.000Z","fetchedAt":"2026-08-18T14:36:31.059Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-17-pool-name-analytics-filter/","media":[],"coverageCount":0},{"id":"rel_-w7j-pD6OyJqhj-zXKRlp","version":null,"type":"feature","title":"SSL/TLS - Certificate Transparency Monitoring is now Generally Available","summary":"Certificate Transparency Monitoring is now generally available on all Cloudflare plans. Alerts for certificates Cloudflare issues on your behalf are automatically filtered, and alert emails are clearer with structured certificate details and a direct link to manage CT Monitoring in the dashboard.","titleGenerated":"Application Performance: Certificate Transparency Monitoring now GA on Cloudflare","titleShort":"CT monitoring generally available across all plans","breaking":"none","importance":4,"content":"Certificate Transparency Monitoring is now [generally available ↗](https://blog.cloudflare.com/certificate-transparency-monitoring-ga) across all Cloudflare plans.\n\nAlerts for certificates Cloudflare issues on your behalf (Universal SSL renewals, backup certificates, Advanced Certificate Manager, Total TLS) are now automatically filtered out. Alert emails are also clearer and more actionable, with structured certificate details and a direct link to manage CT Monitoring in the Cloudflare dashboard.\n\nLearn more in the [launch blog post ↗](https://blog.cloudflare.com/certificate-transparency-monitoring-ga) or the [CT Monitoring docs](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/certificate-transparency-monitoring/).","publishedAt":"2026-08-13T00:00:00.000Z","fetchedAt":"2026-08-13T16:55:13.843Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-13-ct-monitoring-ga/","media":[],"coverageCount":0},{"id":"rel_vIr_qQVpEMDMfRb68YAP-","version":null,"type":"feature","title":"Load Balancing - Load Balancing health notifications now resolve automatically","summary":"Load Balancing health notifications are now stateful: when a pool or endpoint recovers, the follow-up notification matches the original alert and resolves the incident automatically, with no configuration change. Recovery notifications are now sent alongside failure notifications, matching Health Checks behavior. Renaming an endpoint while an incident is open prevents the match, leaving the incident open until closed manually.","titleGenerated":"Cloudflare Application Performance load balancing health notifications now auto-resolve","titleShort":"Load balancing health incidents auto-resolve on recovery","breaking":"none","importance":3,"content":"[Load Balancing](https://developers.cloudflare.com/load-balancing/) health notifications are now stateful. When a pool or endpoint becomes unhealthy, the notification opens an incident in your alerting tool as before. When that same pool or endpoint recovers, the follow-up notification is matched to the original alert and resolves that incident automatically, so you no longer have to close it by hand.\n\nAs part of this change, Load Balancing also sends a notification when a pool or endpoint returns to a healthy state, not only when it becomes unhealthy. Expect to see recovery notifications alongside the failure notifications you already receive.\n\nThis applies to your existing Load Balancing health alerts with no configuration change, and it matches the behavior already used by [Health Checks](https://developers.cloudflare.com/health-checks/) notifications.\n\nTwo things to keep in mind:\n\n- A recovery notification is matched to the earlier unhealthy notification for the **same pool or endpoint**. Renaming an endpoint while an incident is open prevents the match, so that incident stays open until you close it.\n- If a health change cannot be classified as either healthy or unhealthy, the notification is still delivered, but without the state needed to open or resolve an incident.\n\nRefer to [Integrate with PagerDuty](https://developers.cloudflare.com/load-balancing/additional-options/pagerduty-integration/) to learn more about routing Load Balancing health notifications to an incident management tool.","publishedAt":"2026-08-07T00:00:00.000Z","fetchedAt":"2026-08-18T14:36:31.059Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-07-stateful-health-notifications/","media":[],"coverageCount":0},{"id":"rel_CWLEGlh_SsPwUTlqMVG8r","version":null,"type":"feature","title":"Load Balancing - See fallback pool traffic separately in load balancing analytics","summary":"Load balancing analytics now labels fallback pool traffic with the pool name followed by \"(Fallback)\", shown as its own series in requests over time, a separate segment in pool distribution, and a separate card in top endpoints. Previously, fallback traffic sharing a pool name with steering-routed traffic was grouped into a single series.","titleGenerated":"Cloudflare Application Performance separates fallback pool traffic in load balancing analytics","titleShort":"Fallback pool traffic shown separately in analytics","breaking":"none","importance":3,"content":"Load balancing analytics now shows traffic served by your [fallback pool](https://developers.cloudflare.com/load-balancing/understand-basics/health-details/#fallback-pools) separately from traffic routed to the same pool by normal steering.\n\nPreviously, requests were grouped by pool name alone. If the pool acting as your fallback also received traffic through your steering policy, both appeared as a single series, so it was not obvious from the graph whether Cloudflare was still making health-based routing decisions or had fallen back to the pool of last resort. Because the fallback pool ignores health, that distinction matters when you are diagnosing an outage or reviewing how much traffic was shed.\n\nFallback traffic is now labeled with the pool name followed by `(Fallback)`. A pool named `eu-west`, for example, is shown as `eu-west (Fallback)`. This label appears as its own entry in:\n\n- **Requests over time**, as a separate series in the chart.\n- **Pool distribution**, as a separate segment.\n- **Top endpoints**, as a separate card for the pool.\n\nThe **Latency** view and the health event **Logs** are unchanged.\n\nTo see this, go to **Traffic** > **Load Balancing Analytics** for a zone. The same breakdown appears in the analytics view for an individual load balancer under **Load Balancing** at the account level.\n\nRefer to [load balancing analytics](https://developers.cloudflare.com/load-balancing/reference/load-balancing-analytics/) to learn more.","publishedAt":"2026-08-03T00:00:00.000Z","fetchedAt":"2026-08-18T14:36:31.059Z","url":"https://developers.cloudflare.com/changelog/post/2026-08-03-fallback-pool-analytics/","media":[],"coverageCount":0}],"pagination":{"nextCursor":"2026-08-03T00:00:00.000Z|2026-08-18T14:36:31.059Z|rel_CWLEGlh_SsPwUTlqMVG8r","limit":20},"summaries":{"rolling":null,"monthly":[]}}