Chrome ships every 14 days from 8 September 2026: the release-cadence playbook for web and QA teams

Summary. Chrome moved from a four-week to a two-week release cycle with the stable release of Chrome 153 on 8 September 2026, a change announced on 3 March 2026 and covering Desktop, Android and iOS. Extended Stable keeps its eight-week cycle, but it runs on managed Windows and Mac only, so mobile Chrome moves at the new pace whatever your enterprise policy says. The reason is stated plainly in Google's 30 July 2026 security post: in Chrome 149 and 150 the team fixed 1,072 security bugs, more than the previous 23 milestones combined, and it was piloting two security releases per week on top of the two-week milestones. Google also joined a $12.5M donation to the Alpha-Omega project, and Chrome now tracks more than 2,300 third-party dependencies. The consequence for your backlog is arithmetic: any deadline you have filed under a milestone number such as Chrome 158 or Chrome 176 now arrives in half the wall-clock time it would have under the old cadence, unless Google renumbers it to hold the date, as it did for XSLT. XSLT removal at Chrome 158 lands on 17 November 2026, exactly 12 weeks after Chrome 152 on 25 August 2026.

This is what to change in testing, CI and enterprise rollout now that the two-week milestones are running.

What actually changes on 8 September

Since the stable release of Chrome 153 on 8 September 2026, Chrome has put out a new beta and a new stable version every two weeks on Desktop, Android and iOS; the announcement left the Dev and Canary channels as they were. Each version reaches Beta about three weeks before it reaches Stable. The rhythm bends at the year end: Chrome 158 is due on 17 November 2026, Chrome 159 three weeks later on 8 December 2026, and Chrome 160 on 5 January 2027.

The schedule Google published in March for the transition milestones shows how compressed the branch-to-stable path became:

Read the M154 column carefully. Under the old schedule M154 would have branched on 21 September; under the new one it branched on 31 August, three weeks earlier. If your compatibility testing keys off the branch date, every window since then has been shorter in the same way.

From 2021 until September 2026 Chrome shipped a milestone every four weeks. In 2023 the team added a weekly security update to shorten the patch gap, and an Early Stable release that goes to a small share of users first so quality problems surface sooner. The two-week cadence is the next step in that sequence rather than a departure from it. Ben Mason and Deepak Ravichandran of the Chrome team, who wrote the announcement, argue that each release now carries less change, so more frequent releases should disrupt less and be easier to debug after they ship.

Why Chrome is doing this: the bug curve moved first

The cadence change follows a change in how many security bugs Chrome finds. Google's Chrome Security Team documented the mechanism on 30 July 2026.

In early 2026 the team built a Gemini-based agent harness to hunt for vulnerabilities across the Chrome codebase. One result was a sandbox escape through which a compromised renderer could get the browser to read local files; the flaw had sat unnoticed in the code for more than 13 years. By March 2026 the Chrome Vulnerability Reward Program had received more bug reports than in the whole of 2025, which forced a change to the programme's rules.

The fix rate followed. Triage of a single security report historically took 5 to 30 minutes or more of human expertise; an automated pipeline now handles filtering, reproduction, metadata enrichment and routing, saving what Google estimates at hundreds of developer hours per month. BigSleep and CodeMender run inside continuous integration every 24 hours across all changelists, and in May 2026 alone that blocked more than 20 vulnerabilities from reaching production, including one critical issue.

Which brings the number that explains the release calendar: across Chrome 149 and 150, the team fixed 1,072 security bugs, more than the total fixed across the previous 23 milestones combined.

Fixing bugs faster creates a second problem, and Google names it. As soon as a fix is visible in the public source tree, attackers can study it and build an exploit before the patched build reaches users. That window is the patch gap, and N-day exploitation lives in it. The Chrome Security Team's conclusion is blunt: against fast-moving attackers using AI, even weekly security updates are too slow, so Chrome is trialling two security releases a week.

So the real 2026 cadence for a security-sensitive fleet is not fourteen days. It is a major milestone every fourteen days, weekly security updates, and a pilot of two security releases per week on top.

The change that will actually bite: milestone deadlines arrive twice as fast

Most teams track web platform deadlines by milestone number, because that is how Chrome publishes them. A removal pencilled in for a given milestone used to convert into a date at roughly four weeks per milestone. That conversion is now wrong by a factor of two.

The XSLT removal timeline is the cleanest illustration, because Chrome publishes it with both milestone numbers and dates, and the numbers changed when the cadence did:

Count the gap between Chrome 152 on 25 August 2026 and Chrome 158 on 17 November 2026: six milestones in 12 weeks, two weeks apiece. For XSLT, Google held the dates and moved the numbers. In November 2025 the same plan put removal at Chrome 155 on 17 November 2026 and the end of the trial and policy at Chrome 164 on 17 August 2027; after the cadence change those dates became Chrome 158 and Chrome 176. Anyone who wrote the deadline down as Chrome 155 now has the wrong milestone, and anyone converting milestone numbers at four weeks apiece has the wrong date.

Two practical consequences follow. First, audit every milestone-numbered deadline in your backlog and re-derive its calendar date from the Chromium Dashboard rather than from arithmetic you did last year. Second, the escape hatches shrink in the same proportion. A deprecation trial or enterprise policy that buys you 18 milestones is now 36 weeks, not 72. For XSLT the end point is already published: policy and trial coverage runs to Chrome 176 on 17 August 2027, and if you have RSS or Atom feeds relying on client-side transformation, our Chrome XSLT removal migration guide walks through the polyfill and server-side rendering options.

For context on how little of the web this particular removal touches: about 0.02% of page loads use XSLT at all, and fewer than 0.001% use XSLT processing instructions. The removal is driven by security rather than usage, with libxslt vulnerabilities including CVE-2025-7425 and CVE-2022-22834 cited by the Chrome engineers who published the plan, Mason Freed and Dominik Röttsches.

Extended Stable, and why it is not the answer for most teams

Extended Stable dates from 2021 and exists for enterprise administrators and Chromium embedders that need longer to roll out updates; it keeps its eight-week cycle. The mechanics matter: for the first two weeks of a milestone, Stable and Extended Stable carry the same build, and for the next six weeks Extended Stable gets a weekly refresh with the security fixes that also went to Stable, where Google can back-port them.

The limitation is platform coverage. Extended Stable runs only on managed Windows and Mac devices, with no support on iOS or Android. If a meaningful share of your traffic or your workforce is on mobile Chrome, Extended Stable does not slow anything down for them, and your compatibility exposure runs at the full two-week pace regardless of what the desktop fleet does.

Google's own enterprise guidance for keeping fleets current is specific: apply the RelaunchNotification policy so users are prompted and eventually forced to restart for a pending update, keep Extended Stable for the most sensitive environments, where every software change has to be vetted first, and use the Chrome Enterprise Core or Premium dashboard to track fleet-wide versions. That first item is the one most organisations skip, and it is the one that closes the gap between a patch being released and a patch being applied.

Google is also working on removing the restart requirement entirely. Dynamic patching would use Chrome's multi-process architecture to swap updated code into background child processes such as the renderer and GPU process while the browser keeps running. In Chrome 150 a narrower version already shipped: on macOS, where applications commonly keep running with no windows open, Chrome now restarts itself automatically if an update is pending in that windowless state.

What to change in testing and CI

The honest summary is that nothing about this change is hard. It is that everything about it is scheduled, and schedules rot quietly.

Stop pinning browser versions by hand

A pinned ChromeDriver or Puppeteer version in a Dockerfile that someone bumped every four weeks now needs bumping every two. Move the version to a single variable resolved at build time and fail the build loudly when the resolved version drifts more than one milestone from production traffic. Manual bumps double in frequency and halve in reliability.

Add a beta lane, and give it a budget

Chrome recommends testing against the beta, which ships about three weeks before each stable release. Under the old cadence a weekly beta smoke run was arguably optional. With fourteen days between stable releases, beta is the only place a regression can be caught before it is in front of users. A nightly run of your critical-path suite against Chrome Beta is the highest-value single change on this list.

Instrument deprecations rather than reading changelogs

The Reporting API surfaces deprecation reports directly from production traffic, and the pattern is a few lines:

            new ReportingObserver((reports, observer) => {
  reports.forEach((report) => {
    // report.body.id names the deprecated feature, for example "XSLT"
    sendToTelemetry(report.body.id);
  });
}, {types: ["deprecation"], buffered: true}).observe();
          

That inverts the problem. Instead of a person reading two release notes a month and guessing what applies, your own traffic tells you which deprecated features you are still using and roughly when they disappear.

Enable the Legacy Technology Report for managed fleets

Chrome Enterprise can collect deprecated-feature usage across managed browsers and report it back, which is the fleet-level equivalent of the Reporting API snippet. It is the fastest way to find the internal line-of-business application nobody owns that still depends on something being removed in six milestones.

Re-time your release train against theirs

If you freeze changes during a Chrome stable week, you are now freezing every other week. That is not sustainable, so pick the opposite posture: keep shipping, and rely on beta-lane detection plus a fast rollback rather than on calendar avoidance.

India-specific considerations

Three points change the calculus for Indian teams.

Mobile share makes Extended Stable a partial answer at best. Because Extended Stable does not run on Android or iOS, an Indian consumer product with a mobile-heavy audience gets no cadence relief on the surface where most of its traffic sits. Plan compatibility testing around the two-week Stable cadence for mobile web regardless of what the desktop fleet policy says.

Change-management windows need rewriting, not stretching. Regulated environments in BFSI and healthcare typically run browser updates through a change advisory board on a monthly rhythm. A fortnightly cadence with weekly security refreshes, plus a pilot of two security releases per week, does not fit a monthly board. The workable pattern is a standing pre-approval for browser security updates with an exception process, rather than a per-release approval that guarantees your fleet runs behind.

Fleet telemetry is personal data. If you turn on the Legacy Technology Report or a Chrome Enterprise dashboard, you are collecting per-user browsing signals from employee devices. Under the Digital Personal Data Protection Act 2023 that is personal data with a fiduciary attached, and failure to keep reasonable security safeguards around it carries penalties reaching Rs 250 crore. Set a retention period, restrict access to the security team, and write the purpose down before you enable it, not after.

A five-week catch-up plan

Week one: pull every milestone-numbered deadline your team tracks and re-derive the calendar date from the Chromium Dashboard. Expect at least one to have moved by months or to carry a new milestone number.

Week two: replace hardcoded browser versions in CI with a resolved variable, and add an alert when the resolved version drifts from production traffic by more than one milestone.

Week three: stand up a Chrome Beta lane running your critical-path suite nightly. Route its failures to the same place as production alerts, not to an unread channel.

Week four: deploy the ReportingObserver snippet to production and give it two weeks to collect. For managed fleets, enable the Legacy Technology Report in parallel.

Week five: take the deprecation list your own traffic produced, put calendar dates on it, and decide per item whether you migrate, take the origin trial, or take the enterprise policy. Anything relying on an escape hatch needs an owner and a date, because the hatches close on milestone numbers too.

Teams that run enterprise browser fleets should fold this into the same review as their browser security controls; the enterprise controls for agentic browsers piece covers the policy surface that has grown alongside the release cadence, and the wider 2026 web platform developer guide sets out the rest of this year's platform commitments.

FAQ

How eCorpIT can help

eCorpIT builds the release engineering around this kind of change: beta-lane test infrastructure, browser version resolution in CI, deprecation telemetry wired into the alerts your team already reads, and a change-management pattern that survives a fortnightly upstream cadence. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we design applications aligned with Digital Personal Data Protection Act 2023 requirements where fleet or usage telemetry is collected. If your QA schedule was built around four-week browser releases, talk to our engineering team about moving it to the fortnightly cadence.

References

1. Removing XSLT for a more secure browser, snapshot of 2 November 2025 — Chrome for Developers via the Internet Archive

1. Get features faster with Chrome's two-week release cycle - Ben Mason and Deepak Ravichandran, Chrome for Developers, 3 March 2026.

1. Stronger with every update: how we're making Chrome and the web safer in the AI era - Chrome Security Team, Google, 30 July 2026.

1. Removing XSLT for a more secure browser - Mason Freed and Dominik Roettsches, Chrome for Developers, 29 October 2025.

1. Extended Stable channel - Chrome Enterprise and Education Help.

1. Chromium Dashboard release schedule - authoritative milestone dates.

1. Get started with origin trials - Chrome for Developers, including deprecation trials.

1. Feature deprecation and removal in Chrome - Chrome for Developers.

1. Chrome release notes - per-milestone changes.

1. Speeding up Chrome's release cycle - Chromium Blog, March 2021, the four-week change.

1. Early Stable releases - Chrome for Developers.

1. Chrome browser release channels - Chrome Enterprise and Education Help.

1. RelaunchNotification policy - Chrome Enterprise and Education Help.

1. Penalties and adjudication under India's DPDP Act 2023 - King Stubb and Kasiva.

Last updated: 11 November 2026.