Cloudflare’s HTTP hashing function broadens controlled rollouts

A rule-level building block for partial changes

Cloudflare announced general availability of hash_in_range for HTTP products on all plans on October 2. The function maps input fields to an integer in a specified range, allowing a rule to select part of the traffic. Its examples use a random seed for approximately ten percent of requests and custom hostname metadata to control rollout percentages in Cloudflare for SaaS. A missing metadata value can be given a zero-percent fallback.

This makes selective changes easier to express close to the request path. A team can introduce a route or policy to a limited fraction of traffic before expanding it. It can also assign different rollout percentages to customer hostnames rather than maintain a separate rule for every tenant. Those are useful primitives, but the expression alone does not determine whether the selected cohort is appropriate for the feature being introduced.

Source: Cloudflare official changelog

Analysis: Request sampling and user cohorts differ

Selecting requests at random is suitable for some experiments and operational probes. It can be confusing for a user-facing feature if consecutive requests from the same person take different paths. An authentication flow or checkout may require a consistent experience throughout a session. The input used for hashing should reflect the unit the team intends to control, and the design must avoid exposing private identifiers unnecessarily in rule configuration or logs.

A percentage also describes exposure, not success. Ten percent of requests may include a very different share of expensive operations or important customers. Define the actual risk being limited: request count, affected accounts, writes or infrastructure load. For a migration that changes state, account-level consistency may matter more than a neat traffic ratio. The rollout design should explain how the application behaves when a selected request interacts with state created through the previous path.

Use the function inside a measured release process

Establish health checks before enabling a partial change. Track errors, latency and the business outcome that the feature is supposed to improve. Compare cohorts over a useful period rather than expanding immediately after a quiet minute. Assign a person who can stop the rollout, and keep the rollback action simple enough to use while an incident is unfolding. A technically elegant rule is less helpful if the team cannot identify which path caused a failure.

For hostname-based rollout metadata, verify defaults and validate the allowed percentage range in the system that writes the metadata. A missing value should have a predictable and documented result. Keep a history of changes so an investigator can reconstruct which cohort was exposed at a particular time. Cloudflare’s function lowers the barrier to controlled HTTP changes. It works best when the selected unit, operational measurements and reversal process are defined as carefully as the percentage expression itself.