Chrome Web Store review time: how long extension review takes and how to track when your update reaches users

On October 2, 2026, a developer asked in the Chromium Extensions group whether their submission could be reviewed faster. The answer from Chrome's developer relations team was short: "We don't offer expedited review, and review time is generally out of your control." That is the reality of Chrome Web Store review time. You cannot buy your way to the front of the queue, so the only things you control are what you submit, when you submit it, and how quickly you notice where it is stuck.

This guide covers how long review takes in 2026 according to Google's own documentation and announcements, what makes it slower, how to measure your real review times with the Chrome Web Store API, and why "approved" is not the same as "your users have it". It ends with a simple release log that tracks Chrome, Edge and Firefox side by side.

Key takeaways

• Google's official answer: "For most extensions, review is completed within a few days, but it can take up to a few weeks." Contact support if an item is pending for more than three weeks.
• New developers, new extensions, sensitive permissions, broad host access and large code changes all lengthen review. Keep risky changes out of urgent bug-fix releases.
• There is no expedited review. Submit early and use deferred publishing to choose the release moment yourself.
• The fetchStatus method of the Chrome Web Store API reports PENDING_REVIEW, STAGED, PUBLISHED and REJECTED, which is enough to log your own review times automatically.
• After approval, Chrome checks for updates "every few hours" and may wait until your service worker is idle before applying one. Edge and Firefox run separate queues, so track each store's live version.

Chrome Web Store review time: how long does review take?#

The Chrome Web Store review process documentation gives the official range: "For most extensions, review is completed within a few days, but it can take up to a few weeks." If an item has been pending for more than three weeks, Google asks you to contact developer support.

2026 has been uneven. On April 23, Chrome's developer relations team posted a PSA about longer review times, citing "a surge in new extensions being submitted to the Chrome Web Store". Replies in that thread described a 28-day wait for a critical bug fix on an extension with 200,000 monthly installs. On August 20, the store's review and publishing update said the team had "optimized our review processes and prioritization framework, bringing review levels back to expected baselines", and added pre-submission installation testing that flags a broken package as soon as you upload it. We covered the rest of that announcement in our roundup of Chrome Web Store changes in 2026.

The other stores your extension ships to work on their own clocks:

None of these numbers is a promise, and averages from other developers say little about your extension. Your own history is the only benchmark that matters, which is why the measurement section below is worth the half hour it takes to set up.

What makes Chrome Web Store review slower#

Google's documentation lists the signals that extend review. Paraphrased, they are:

• New developers and new extensions. Your first submissions get more scrutiny than updates from an established account.
• Sensitive permissions. Permissions with powerful warnings take longer.
• Broad host permissions. Patterns such as <all_urls>, *://*/* and https://*/* are called out by name.
• Significant code changes. A large diff gets more attention than a small one.
• Code that is hard to read. A large or obfuscated bundle takes longer to review. Minification is allowed; obfuscation is not.

What this means for planning a release:

1. Separate risky changes from urgent ones. If a bug fix is urgent, ship it on its own. Adding a new permission or host pattern in the same version puts the fix behind a slower review and, if the permission adds a warning, can disable the extension for existing users until they accept it. Our guide to why Chrome extension weekly users drop shows how costly that can be.
2. Prefer optional and narrow permissions. activeTab, optional_permissions and optional_host_permissions reduce both review risk and warning risk.
3. Do not cancel and resubmit to "unstick" a review. Cancelling is meant for when you find a bug after submitting. The new package goes through review from the start, so resubmitting the same code only resets your wait.
4. Submit before you need it. Google's publishing documentation lets you uncheck automatic publishing. The item then waits after approval, and "once the review is complete, you will have up to 30 days to publish" before it reverts to a draft. That turns review time from a blocker into lead time: submit a week early, publish on launch day.

Measure your own review time with the Chrome Web Store API#

The Developer Dashboard shows where a submission stands right now, but it is not built to give you a history of review durations across releases. The Chrome Web Store API fills that gap. Its fetchStatus method returns the state of the submitted and the published revision of your item, and the ItemState values include PENDING_REVIEW, STAGED (approved and ready to publish), PUBLISHED, PUBLISHED_TO_TESTERS, REJECTED and CANCELLED. The response also carries the version in each distribution channel, its deploy percentage, and two booleans, takenDown and warned.

Setup takes three pieces, all described in Google's guide to using the API: an OAuth client with the Chrome Web Store API enabled, a refresh token, and your publisher ID, which "is displayed in the Publisher > Settings section" of the dashboard. The read-only scope https://www.googleapis.com/auth/chromewebstore.readonly is enough for status checks.

This script polls the status and appends a line to a log whenever anything changes. Run it every 30 minutes from cron or a scheduled CI job:

// review-timer.mjs: run every 30 minutes from cron or a scheduled CI job.
import { appendFile, readFile, writeFile } from 'node:fs/promises';

const {
  CWS_CLIENT_ID,
  CWS_CLIENT_SECRET,
  CWS_REFRESH_TOKEN,
  CWS_PUBLISHER_ID,
  CWS_ITEM_ID,
} = process.env;

async function getAccessToken() {
  const res = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    body: new URLSearchParams({
      client_id: CWS_CLIENT_ID,
      client_secret: CWS_CLIENT_SECRET,
      refresh_token: CWS_REFRESH_TOKEN,
      grant_type: 'refresh_token',
    }),
  });
  if (!res.ok) throw new Error(`token request failed: HTTP ${res.status}`);
  return (await res.json()).access_token;
}

async function fetchStatus() {
  const name = `publishers/${CWS_PUBLISHER_ID}/items/${CWS_ITEM_ID}`;
  const res = await fetch(
    `https://chromewebstore.googleapis.com/v2/${name}:fetchStatus`,
    { headers: { authorization: `Bearer ${await getAccessToken()}` } },
  );
  if (!res.ok) throw new Error(`fetchStatus failed: HTTP ${res.status} ${await res.text()}`);
  return res.json();
}

/** "PENDING_REVIEW 1.4.0" or "PUBLISHED 1.3.2 (50%)" */
function describe(revision) {
  if (!revision) return null;
  const builds = (revision.distributionChannels ?? []).map((channel) =>
    channel.deployPercentage === undefined
      ? channel.crxVersion
      : `${channel.crxVersion} (${channel.deployPercentage}%)`,
  );
  return [revision.state, ...builds].join(' ');
}

const status = await fetchStatus();
const snapshot = {
  submitted: describe(status.submittedItemRevisionStatus),
  published: describe(status.publishedItemRevisionStatus),
  takenDown: status.takenDown ?? false,
  warned: status.warned ?? false,
};

const previous = await readFile('review-state.json', 'utf8').catch(() => '{}');
if (previous !== JSON.stringify(snapshot)) {
  const entry = { at: new Date().toISOString(), ...snapshot };
  await appendFile('review-log.jsonl', `${JSON.stringify(entry)}\n`);
  await writeFile('review-state.json', JSON.stringify(snapshot));
  console.log('Status changed:', entry);
}

A second script turns the log into review durations:

// durations.mjs: print how long each submission waited in review.
import { readFileSync } from 'node:fs';

const entries = readFileSync('review-log.jsonl', 'utf8')
  .trim()
  .split('\n')
  .map((line) => JSON.parse(line));

let pendingSince = null;
for (const entry of entries) {
  const pending = entry.submitted?.startsWith('PENDING_REVIEW') ?? false;
  if (pending && !pendingSince) pendingSince = entry;
  if (!pending && pendingSince) {
    const hours = (Date.parse(entry.at) - Date.parse(pendingSince.at)) / 36e5;
    console.log(`${pendingSince.submitted}: ${hours.toFixed(1)} h, then ${entry.submitted ?? entry.published}`);
    pendingSince = null;
  }
}

With a 30-minute poll, each duration is accurate to within half an hour, which is plenty. After a few releases you will know what "normal" looks like for your extension, and you can tell a slow week from a stuck submission without guessing.

Two practical notes. First, if fetchStatus returns 403 PERMISSION_DENIED, check the item ID and the publisher before anything else: in a September 29, 2026 thread about exactly that error, the reply pointed out that the item ID was not one the store had any history of. Second, the warned and takenDown flags are worth alerting on by themselves. A policy warning has a deadline, and you want to hear about it from your own monitoring, not from users.

Approved is not the same as installed#

When the state flips to PUBLISHED, the new version is available, but your users do not have it yet.

• Chrome checks for updates every few hours. The extension update documentation says: "Every few hours, the browser checks installed extensions for an update URL." Browsers that are closed pick the update up the next time they run.
• A running extension may wait. The runtime API reference describes onUpdateAvailable as "Fired when an update is available, but isn't installed immediately because the app is currently running." Listen for it and call chrome.runtime.reload() at a safe moment if an update must apply quickly.
• A partial rollout limits who gets it. If you set a deploy percentage below 100, only that share of users receives the version. The deployPercentage field in fetchStatus shows where a rollout stands.
• A permission warning holds it back. Users who do not accept a new warning keep the extension disabled instead of running the new version.

You can confirm which version the store is serving by asking the update service Chrome itself uses. It is not a documented public API, so call it sparingly, but a single request answers the "is it live yet?" question:

curl -s "https://clients2.google.com/service/update2/crx?response=updatecheck&acceptformat=crx3&prodversion=141.0.0.0&x=id%3Dddkjiahejlhfcafbddmgiahcphecmpfh%26uc" \
  | grep -o 'version="[^"]*"'
# version="2026.930.1227" (uBlock Origin Lite, at the time of writing)

To see how many users actually run the new version, use the Weekly Users page in the dashboard broken down by item version, or record chrome.runtime.getManifest().version in the telemetry you already send. The onInstalled event with reason update also gives you previousVersion, which tells you which upgrade path each user took.

Track review time across Chrome, Edge and Firefox#

If you publish on more than one store, each store has its own review queue, and for a while after every release your users are split across versions. A bug report that says "the new button is missing" might come from an Edge user still on last week's build. Keep one release log for all stores. The rows below are an example of the format:

The "live" columns are what matter to users, so fill them from what each store's public listing shows, not from the moment you received an approval email. Our post on tracking one extension across Chrome, Edge and Firefox explains why the three listings drift apart, and what to watch in the week after an extension release covers the checks that follow.

Filling in that table by hand gets old quickly. Extenify's extension version tracker records the live version on every store your extension ships to, flags a store that is left behind on an older build, and includes a "new version published" line in your daily alert when a store picks up a release, so you know the day an update reaches users on Chrome, Edge and Firefox without checking three listings. It works for any public listing, so you can follow a competitor's release cadence too. Tracking your first extension is free; the pricing page has the details for larger portfolios.

Frequently asked questions#

How long does Chrome Web Store review take for an update?#

Google says most reviews finish within a few days and some take up to a few weeks. Updates without new permissions or large code changes are usually faster than new items. Log your own submissions with the fetchStatus script above to learn your typical time.

Can I request expedited review on the Chrome Web Store?#

No. On October 2, 2026, Chrome's developer relations team answered a request for expedited review with "We don't offer expedited review, and review time is generally out of your control." Submitting early with deferred publishing is the closest substitute.

What should I do if my extension has been pending review for weeks?#

Wait until it has been pending for more than three weeks, then contact Chrome Web Store developer support, as the review process documentation recommends. Do not cancel and resubmit the same package, because the new submission starts its review from the beginning.

My update was approved, so why do users still have the old version?#

Chrome checks for updates every few hours, closed browsers update the next time they run, and a running extension may wait until it is idle. A partial rollout or a new permission warning can also keep users on the old version. Check the deploy percentage and your permissions first.

How long does Edge Add-ons and Firefox Add-ons review take?#

Microsoft says Edge certification can take up to seven business days. Mozilla says it can take up to 24 hours for a Firefox submission to be signed and published, longer if it is selected for manual review.

Summary#

Chrome Web Store review time is mostly out of your hands, but the delay it causes is not. Keep urgent fixes free of new permissions, submit early and publish when you are ready, and log every submission with the API so you know your real numbers. Then remember that approval is only the start: Chrome needs hours to roll an update out, other stores run their own queues, and the only reliable answer to "do users have it yet?" is the live version on each store's listing.

Image credits#

• Cover photo: Round Silver-colored Analog Stopwatch on Brown Wooden Panel by Anton Makarenko on Pexels, Pexels License.