Update src/content/changelog/workers/2025-03-22-smart-placement-stablization.mdx

Co-authored-by: korinne <[email protected]>

Author: markjmiller

src/content/changelog/workers/2025-03-22-smart-placement-stablization.mdx

@@ -7,6 +7,10 @@ products:
 date: 2025-03-22T00:00:00Z
 ---
 
-[Smart Placement](https://developers.cloudflare.com/workers/configuration/smart-placement/) figures out potentially better locations to run Workers and Pages Functions. There are heuristics to get these compute resources placed in optimal locations that are different from default locations (closest to where the request is received). Previously if these heuristics were not consistently met, compute would return to running in default locations. Now after heuristics have been met at least once, dropping below them won't unset optimal locations.
+[Smart Placement](https://developers.cloudflare.com/workers/configuration/smart-placement/) is a unique Cloudflare feature that can make decisions to move your compute (your Worker or Pages Functions) to run in a more optimal location (such as closer to a database). Instead of always running in the default location (the one closest to where the request is received), Smart Placement uses certain “heuristics” (rules and thresholds) to decide if a different location might be faster or more efficient.
+
+Previously, if these heuristics weren’t consistently met, your compute resources would revert to running in the default location — even after they had been optimally placed. This caused issues when request patterns dipped for a while. The system would reset to the default location, rather than remaining in the optimal one.
+
+Now, once Smart Placement has identified and assigned an optimal location, temporarily dropping below the heuristic thresholds will not force a return to the default location. This update prevents your compute from repeatedly shifting back and forth and ensures it stays in the optimal location once Smart Placement has deemed it necessary.
 
 For example in the previous algorithm, a drop in requests for a few days might return to default locations and heuristics would have to be met again. This was problematic for workloads that made requests to a geographically located resource every few days or longer. In this scenario, compute would never get placed optimally. This is no longer the case.