Progressive Delivery
Date: 2026-08-16
Release to a few people, watch, then release to more. It converts deployment from a binary event into a controlled exposure curve — so the blast radius of a bad change is a percentage rather than everyone.
What it is
Progressive delivery is exposing a change to an increasing share of users, with automated checks between stages and the ability to stop or reverse at any point.
It’s built on Feature Flags — the flag is the mechanism, this is the practice.
stage 1 internal users only catch the obvious
stage 2 1% real traffic, real devices, real blockers
stage 3 5% watch 24h enough volume for error rates to be visible
stage 4 25% watch 24h enough for business metrics to move
stage 5 100%
Each stage answers a different question, which is why skipping to 50% loses most of the value.
The patterns
| Pattern | Splits by | Suits |
|---|---|---|
| Canary | A small percentage of traffic | Most web changes |
| Percentage rollout | Deterministic hash of user ID | Anything needing a consistent experience |
| Ring deployment | Cohorts: staff → beta users → everyone | Organisations with a willing internal population |
| Blue-green | Two full environments, traffic switched | Infrastructure changes, where partial isn’t possible |
| Geographic | Region | Where behaviour or regulation varies by market |
Percentage by deterministic hash is the default for web. Randomising per request means a user sees the new checkout on one page and the old one on the next, which is worse than either — see Assignment and Bucketing.
What to watch between stages
The stages are only useful if something is actually being checked, with a threshold agreed in advance.
- Error rate, by arm. The primary automated gate
- Latency and Core Web Vitals, by arm
- Business guardrails — conversion, add-to-basket, revenue per visitor — Guardrail Metrics
- Support contact volume, which lags but catches things instrumentation doesn’t
Automate the rollback trigger. A rollout that requires a human to notice a dashboard at 2am isn’t a safety mechanism. Most platforms support automatic halt on an error-rate threshold, and that’s the minimum worth having.
It is not an experiment
The distinction that matters and gets blurred constantly.
A ramp gives you exposure control. It does not give you a comparison, because the sequential reading — this week at 25% versus last week at 0% — is confounded with time, traffic mix and everything else that changed.
To learn anything causal you need a concurrent held-back group, randomly assigned, measured at the same time. See Rollouts as Experiments.
In plain terms: progressive delivery tells you whether the change broke anything. It doesn’t tell you whether the change helped. Those are different questions and only one of them is answered by ramping.
What it needs to work
- Flags with instant propagation. A rollback that takes a deploy isn’t a rollback
- Metrics segmented by arm. If you can’t compare treated and untreated, you’re watching aggregates and won’t see a 5% cohort failing
- Backwards-compatible changes. Both versions run simultaneously, so the database schema, APIs and message formats must serve both — Backwards Compatibility, Database Migrations
- A decision to stop. Written thresholds, agreed before launch, or the ramp continues on optimism
That third point is the one that catches teams out: progressive delivery constrains what kind of change you can make. Anything requiring old and new to coexist has to be designed for it, which usually means expand-contract rather than a single cutover.
Where it fits
- Feature Flags — the mechanism
- Rollback and Forward Fix — what happens when a stage fails
- trunk-based development — the branching model that makes frequent small releases possible
- Edge Computing — a natural place to evaluate the percentage, close to the user
- Continuous Deployment — progressive delivery is what makes deploying continuously survivable