The State of Preview Deployments 2026

Every pull request ships a live preview URL now, and the rebuild churn behind that URL has quietly become one of the largest hidden line items in a web team CI bill.

Executive summary

Preview deployments, a live and shareable URL built from a pull request and updated on every push, have become the default review surface for web teams. Instead of reading a diff and imagining the result, a reviewer clicks the link, sees the change running against real assets and real routing, and approves or requests changes against the actual rendered behavior. The practice rides on the same CI/CD adoption that now covers most professional developers, and it has quietly reshaped what code review feels like for anyone building a user-facing surface.

The benefit is real and the cost is real, and they live in different places. The benefit lives in the review loop: a preview URL collapses the gap between 'looks right in the diff' and 'works right in the browser', which is exactly the gap where visual and behavioral regressions hide. The cost lives in the rebuilds. A preview is not built once. It is rebuilt on every push to the branch, and an active pull request sees many pushes before it merges. Each rebuild is a full set of build minutes plus a deploy, and a large share of those rebuilds are superseded by the next push before anyone opens them.

This report quantifies both sides. We model how many previews a typical pull request actually triggers across different team velocities, what a single rebuild costs on hosted Linux, Windows, and macOS runners versus a managed alternative, how much real review speed teams recover for that spend, and what fraction of all those rebuilds are ever viewed by a human. The throughline is that previews are worth it, but most teams overpay for them by rebuilding indiscriminately rather than rebuilding deliberately.

Three numbers frame the year. The CI/CD adoption that makes previews possible now reaches roughly three quarters of professional developers, so preview pipelines are not a niche concern, they are a growing share of total build spend. A typical active pull request triggers close to four preview rebuilds before it merges, and high-cadence or trunk-heavy teams push that number into double digits. And a live preview URL cuts median time-to-first-review by a meaningful margin, with the largest additional gain coming from pushing the link to reviewers rather than making them hunt for it.

The encouraging part for engineering leaders is that the waste is mechanical and the fixes are cheap. Debouncing rebuilds so the branch settles before it rebuilds, caching the build so a rebuild restores rather than recomputes, keeping the matrix Linux-first so macOS is reserved for the legs that need it, and auto-healing the transient failures that erode trust in the URL are all configuration rather than rewrites. Done together, they turn previews from a quiet budget worry into a default that pays for itself in faster review.

Previews are the default review surface, not an experiment

The argument over whether to ship a preview per pull request is settled for web teams. A preview URL has become the expected artifact of opening a PR, to the point where reviewers feel under-equipped without one. The reason is that a diff describes intent while a preview describes behavior, and behavior is where the regressions that survive review actually live: a layout that breaks at a real viewport, a route that 404s under real auth, a font that fails to load against a real CDN.

This shift tracks the broader CI/CD adoption curve. Because automated pipelines now reach roughly three quarters of professional developers, the build-and-deploy machinery that a preview needs is already present on most teams. Adding a preview is rarely a new pipeline, it is a new target on an existing one. That low marginal cost to adopt is exactly why previews spread so fast, and also why their compounding rebuild cost crept up on teams unnoticed.

The consequence is that preview pipelines are no longer a rounding error on a build bill, they are a structural share of it. A team that merges dozens of pull requests a week, each rebuilding several times, is running its full build many hundreds of times a month purely to keep preview URLs current. That volume is what makes the per-rebuild economics in this report matter, because a small per-build inefficiency multiplied across that cadence is a large absolute number.

Most preview rebuilds are paid for and never seen

On an active pull request, a new push frequently lands before anyone has opened the preview from the previous push, so the older build is superseded while still unviewed. Modeled across typical push cadence, close to half of all preview rebuilds are paid for in full and never looked at by anyone. They exist for a few minutes as the current preview, then a fresh push retires them before they earn their keep.

This is the preview-specific version of a familiar CI failure mode: doing work proportional to activity rather than proportional to need. Every push triggers a rebuild whether or not the previous rebuild was ever relevant, so a burst of three quick commits to fix a typo can cost three full builds and three deploys, of which only the last is ever the live preview a reviewer sees.

The fix is debouncing. Waiting a short, quiet window for the branch to settle before rebuilding, or rebuilding on demand only when a reviewer asks for the latest, removes most of the superseded-build waste without changing the review experience at all. A reviewer who opens the link a minute after the last push still sees the right build; the difference is that the team stopped paying for the two intermediate builds nobody would ever have opened.

• Close to half of modeled preview rebuilds are superseded before anyone opens the URL.
• A burst of quick commits multiplies builds linearly while only the final build is ever the live preview.
• Debouncing on a short settle window keeps the reviewer experience identical while removing most superseded rebuilds.

Previews speed review, but the notification is the real lever

A live preview URL measurably cuts time-to-first-review. A reviewer who can click and see the change is faster to engage than one who has to reconstruct the change mentally from a diff, and the modeling shows a clear step down in median pickup time the moment a working preview exists.

The larger surprise is where the additional gain comes from. The biggest incremental win is not a faster build, it is pushing the preview link to reviewers the instant it is ready. Teams that automatically post the URL into the review channel or onto the pull request capture the fastest pickup, because the preview arrives in the reviewer's attention rather than waiting to be discovered. Teams that build a perfect preview but leave reviewers to go find it leave most of that benefit on the table.

There is a practical ordering implication here. Shaving build time helps, but it is a smaller lever than closing the human gap between 'preview is ready' and 'reviewer knows it is ready'. The cheapest review-speed improvement available to most teams is not a faster runner, it is wiring the ready event to a notification.

macOS preview builds are the silent budget killer

Web previews built on Linux are cheap, and at published rates a Linux preview build is a small fraction of a dollar. The picture changes entirely for teams shipping mobile or cross-platform previews on hosted macOS runners, where the per-rebuild cost is a large multiple of the Linux equivalent. A single mobile preview pipeline, rebuilt several times per PR across a busy week, can dominate a team's entire build bill.

The pattern repeats the cross-platform trap seen across CI generally: the expensive operating system ends up doing work that did not require it. A great deal of what runs on a macOS preview leg, dependency install, asset bundling, JavaScript build steps, would pass identically on Linux. The expensive runner is paying premium rates to do commodity work, and then that premium is multiplied by the rebuild churn from the previous findings.

The highest-leverage cost cut is to keep the preview matrix Linux-first and reserve macOS only for the legs that genuinely need it, such as native build or platform-specific UI rendering. Combined with debouncing, this is often the difference between a preview bill that scales smoothly and one that spikes every time a mobile-heavy branch goes active.

Caching decides whether a rebuild is cheap or wasteful

Because a preview rebuilds many times across a pull request, the marginal cost of each rebuild is the number that compounds. An uncached rebuild reinstalls dependencies that did not change and reruns build steps that produce bit-for-bit identical output, paying full price every single time. A well-cached rebuild restores the unchanged layers and only rebuilds what the latest push actually touched.

The review-speed chart shows this effect directly: a cached preview build reaches a reviewer faster than a cold one, and faster previews compound into faster review because the reviewer is not waiting on a from-scratch build. Caching is therefore not only a cost lever, it is a latency lever, and on preview pipelines the two reinforce each other.

The discipline is the same as elsewhere in CI. Cache keys scoped to lockfiles and toolchain versions, with hit rates that are actually monitored, keep previews both cheap and fast. A preview pipeline with a cold cache on every push is the worst of both worlds: it is the slowest version of the review-speed benefit and the most expensive version of the rebuild cost.

Failed preview builds quietly erase the benefit

A preview is only valuable if reviewers trust the link. When a preview build fails transiently, a reviewer who clicks a broken URL learns to distrust previews and falls back to reading the diff, which erases the entire reason the preview pipeline exists. The failure does not just waste one build, it degrades the habit that made previews worth running.

Most of these failures are mechanical rather than real. A registry timeout while pulling a dependency, a flaky deploy step, an out-of-memory kill on an undersized runner: these are environment hiccups, not defects in the change. They pass on a clean retry, which means the right response is to retry them automatically rather than to surface a red preview to a reviewer who will draw the wrong conclusion.

Self-healing runners address this directly by retrying a transient failure on a fresh environment before a human sees the broken link. The preview stays reliable enough that reviewers keep relying on it, the trust that makes previews valuable is preserved, and the minutes spent are recovery minutes rather than abandoned ones.

Managed runners change the rebuild math

Preview economics are unusually sensitive to the per-minute rate because the build runs so many times per pull request. A lower per-minute cost does not save once, it saves on every push, on every active PR, every week. That multiplication is why the same rate difference that looks marginal on a single CI run looks decisive on a preview pipeline.

Managed runners model roughly 70 percent lower runner cost than hosted runners, and that delta lands on the most-multiplied workload a web team runs. The same adoption that put CI/CD in front of about 76 percent of professional developers is what makes preview pipelines a large and growing slice of total build spend, so the per-minute savings compound exactly where the volume is heaviest.

The practical takeaway is that the runner layer is not a side concern for preview deployments, it is the primary cost driver. Right-sizing the runner, keeping the matrix Linux-first, caching aggressively, and pricing the per-minute rate low together turn previews from a budget worry into a default a team can leave on without a second thought.

• A lower per-minute rate multiplies across every push of every active PR, so preview pipelines amplify rate differences.
• Managed runners model roughly 70% below hosted rates, landing on the most-repeated workload a web team runs.
• Runner choice, caching, and a Linux-first matrix together decide whether previews are cheap-by-default or a recurring surprise.

Recommendations

Debounce rebuilds so the branch settles before it rebuilds

Stop rebuilding on every push. Wait a short quiet window for the branch to settle, or rebuild on demand when a reviewer asks for the latest. This removes most of the superseded-build waste, which modeling puts near half of all rebuilds, without changing what any reviewer ever sees.

Keep the preview matrix Linux-first

Audit which preview legs truly require macOS or Windows and move everything else to Linux. Reserve the expensive operating systems for native build and platform UI rendering. Because previews rebuild repeatedly, this single reshaping compounds into a large absolute saving on mobile-heavy pipelines.

Cache the preview build and monitor the hit rate

Scope cache keys to lockfiles and toolchain versions so a rebuild restores unchanged layers instead of recomputing them. Watch the hit rate the way you watch test coverage. On previews this is both a cost lever and a latency lever, because a cached build also reaches the reviewer faster.

Push the preview URL to reviewers automatically

The largest review-speed gain is not a faster build, it is the notification. Post the ready preview link into the review channel or onto the pull request the moment the build finishes, so the preview arrives in the reviewer attention rather than waiting to be found.

Auto-heal transient preview failures before they reach a reviewer

Most failed preview builds are mechanical: registry timeouts, flaky deploys, OOM kills. Retry them automatically on a fresh environment so a reviewer never clicks a broken link, draws the wrong conclusion, and abandons the preview habit that made the pipeline worthwhile.

Outlook

Preview deployments will keep spreading as the default review surface, and the teams that benefit most will be the ones that treat the rebuild pipeline as a managed cost rather than an automatic reflex. The waste is not inherent to previews, it is inherent to rebuilding indiscriminately, and that distinction is what separates a preview pipeline that scales gracefully from one that spikes whenever a busy branch goes active.

Expect the per-minute rate and the caching layer to become the dominant variables in preview economics through 2026 and beyond. Because the build runs so many times per pull request, small improvements in either compound into large absolute differences, and teams that ignore both will find preview spend growing faster than their merge volume. The optimizations reinforce each other: a cached build on a low-cost runner is both the cheapest and the fastest preview, which means cost and review speed stop being a tradeoff.

The practical direction is clear. Debounce the rebuilds, keep the matrix Linux-first, cache the build, notify the reviewer, and auto-heal the transient failures, and a preview URL on every pull request becomes a default a team can leave on without watching the bill. The organizations that internalize this will get the full review-speed benefit of previews at a fraction of the cost their peers pay for the same feature.

Methodology

This report synthesizes publicly available industry data, including developer surveys and published cloud and CI runner pricing, with Latchkey's own analysis of preview-deployment economics across managed GitHub Actions workloads. Rebuilds per pull request, review-speed deltas, and the rebuild-fate split are modeled estimates derived from typical pull-request shapes and published runner pricing (Linux at $0.008/min, macOS at $0.08/min, managed at $0.0025/min), not a primary survey. Where a figure is attributed to a named source it reflects that source. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• Stack Overflow Developer Survey
• GitHub - Octoverse
• GitHub Actions - billing & pricing
• GitHub Actions documentation

More Latchkey reports