Chrome Web Store pending review: what to do while you wait

What Chrome Web Store pending review actually means

Your package is in the queue or being checked. Google's review docs say things like broad host permissions, sensitive permissions, large code and new accounts get closer examination, so they sit there longer.

If you already have a live version, it keeps serving users the whole time. While you wait, the listing work in Chrome Web Store SEO is the best use of your time.

Google's stated threshold is three weeks. Before that, a long wait isn't a sign of trouble on its own. How long review takes covers the usual range.

A checklist for the wait

Don't spend the wait refreshing the dashboard. Spend it on the listing people will see once it's approved.

The Tools category page has the dated counts if you want to check this yourself.

What not to do

• Don't pull and resubmit over and over hoping for a faster reviewer. Google doesn't say this helps.
• Don't add new permissions to the pending build. That's one of the named slow-down triggers.
• Don't announce a launch date yet.

What each dashboard status means

The developer dashboard uses a handful of labels. They sound alike, so here's what each one tells you to do.

The approved but not published state only appears if you chose deferred publishing. It's the most useful one for launches, because it splits review from release.

Plan the launch around the wait

The safest launch plan treats review as a gap of unknown length and puts it before anything with a fixed date.

1. Submit earlyAim for at least a week before you need to be live.
2. Turn on deferred publishing, so approval doesn't push you live by surprise.
3. Line up the launchposts, emails and screenshots while the item waits.
4. Publish on the day, once approval is in.
5. Post your launchonly after you can open the live listing yourself.

This is the same reason big teams ship small updates. In our crawl observed 3 Oct 2026, 19,443 of 65,655 extensions with store data had an update in the previous 30 days. Those teams live with review every month by keeping each change small.

Good uses of the waiting time

A pending item can't be changed much, but almost everything around it can. These jobs pay off on day one.

• Write the first line of your description the way a user would describe the problem. Our guide to keyword research shows how to find that phrase.
• Make your first screenshot show the result, not the settings page.
• Prepare a short welcome page that opens after install and shows one thing to try.
• Set up a way to hear from users, such as a support email or form, so early bugs reach you before they reach a one-star review.
• Read three rival listings in your niche and note their user counts and rating counts with today's date.

That last job gives you a baseline. A month later, you'll know if your launch did better or worse than the tools you're up against.

When the wait is a warning sign

Most long waits are just long waits. A few patterns are worth acting on before the three-week mark.

• You added a broad permission late, like access to all sites. Consider pulling it into a later update.
• Your code is minified or bundled in a way that's hard to read. Google's policies say logic must be clear from the package.
• Your listing describes several unrelated jobs. The single purpose rule may be in play.

If one of these fits, it can be worth fixing and resubmitting rather than waiting. If none fit, wait for the three weeks, then contact support with your item ID.

What to send support after three weeks

If the three weeks pass, a clear message saves a round of back and forth. Keep it short and factual.

1. Your item ID, from the dashboard URL or item page.
2. The date you submitted, and whether it's a new item or an update.
3. What changedsince the last approved version, in one or two lines.
4. Any permission changes, with the feature each one supports.
5. A polite askfor a status update.

Don't argue the case before there's a verdict. Support can't speed up a reviewer, but a tidy message makes it easy to check where your item stands.

Watching rivals while you wait

The wait is a good time to study the listings you'll sit next to. We're biased, since we build Ext Watch, but our New launches page shows young listings with their user bucket and age, so you can see what else launched in your space recently.

For each close rival, note four things with today's date: users, rating count, last update and the first line of the description. When you're live, you can compare like for like.

After approval

Approval isn't the finish line. The first week live shapes your first reviews.

• Install it yourself from the live listing in a fresh profile.
• Check the welcome flow opens and makes sense.
• Reply to the first reviews within a day, good or bad.
• Write down your day-one numbers, so you can see the first month clearly.

Our guide to Chrome extension marketing picks up from here, with a plan for the first 10,000 users.

Pending review for updates versus new items

The wait feels different depending on what you submitted.

For urgent fixes, keep the update as small as possible. A one-line change with no new permissions gives reviewers the least to check. Our extension pages show how often similar tools ship, which helps you set expectations.

If the answer is a rejection

You'll get an email naming the policy. Fix that one thing, resubmit, or use the Appeal button in the dashboard if you disagree. Google says support usually replies within three days. The full review process is mapped step by step.

We're biased, since we build Ext Watch, but competitors' version dates are one useful thing to look at while you wait. Our extension pages record each version we see and the date we saw it, so you can see how often similar tools ship.

The waiting room is dull. It's a good place to rehearse.