Chrome Web Store Review Time: Why Is It Still Pending?

Chrome Web Store review usually takes a few days, according to Google, though some submissions take a few weeks. Google recommends contacting developer support if yours has been pending for more than three weeks. There is no guaranteed approval date. Google's review guidance

The waiting gets more irritating after you've had a few quick approvals. Once you've seen an update go live within hours, a package still sitting in review the next morning feels as though something has gone wrong.

Before changing anything, I would check exactly what is waiting. An uploaded draft, a pending submission and an approved update waiting for you to publish it need different actions.

Do established developers get faster reviews?

My impression is that an established publishing history and a clean record in the Chrome Web Store can work in your favour when updating an extension. Some of my own updates go through within hours, and publication on the day I submit is common enough that I notice when it takes longer. It feels as though maintaining existing extensions without a history of policy trouble helps.

I can't isolate that from the changes in each package or the queue on that particular day. Google explicitly says submissions use the same review system regardless of developer tenure or user count. It also lists new developers among the signals that can lead to closer inspection, and says reviews can take longer after a rejection or warning. That leaves room for different experiences without establishing a priority lane for older accounts. How Google describes the review system

Those quick approvals are encouraging. I still leave room for a longer review when planning a release.

I maintain Classic View for Google Images, which restores horizontal image rows and adds features such as hover previews and a direct View Image button. I wrote about how that extension started with a Reddit request. Working on an extension like that makes the distinction between finishing a fix and getting it into the store quite practical. You can finish your part while publication is still outside your control.

What does Pending review mean?

Google describes Pending review as a submission waiting in the review queue. The label alone doesn't establish that someone is actively inspecting your code or that they have found a problem. You can check the item's status in the developer dashboard. Checking review status

Before diagnosing a delay, separate these situations:

| What you see | What to check next |
| --- | --- |
| You uploaded a package, but it is still a draft | Check whether you completed the submission for review. Uploading the ZIP is only part of publishing. |
| The submitted version says Pending review | Record its version and submission date. Check for messages about that item. |
| Review passed, but the update is staged | Check whether you selected deferred publishing. It may be waiting for you to publish it. |
| The version was rejected | Read the rejection details and address the stated issue. Waiting longer won't change that decision. |
| The new version is published, but a user reports an older one | Compare the published version with their installed version before treating this as a review problem. |

Google documents submission and deferred publishing separately. If you choose to publish manually after approval, the approved submission can remain staged for up to 30 days. After that it returns to draft and needs another review. Publishing and staged submissions

There is also a useful distinction for updates: submitting one doesn't immediately replace the live version. Existing users and new installations continue to use the previously published version while the update is under review. Updating an existing extension

Write down both version numbers when investigating a report. "The extension is live" and "the fix is live" can describe different states.

Why one extension review takes longer than another

Google identifies broad or sensitive permissions, significant code changes, and large or difficult-to-review code as reasons for closer inspection. Both new extensions and updates go through review. Factors affecting review time

Compare the actual releases. Did this one change a label in the popup, or add access to more websites? Did the package gain a dependency? Does the store description still explain what the current version does?

Those questions help you describe the submission. They won't reveal your place in the queue, and they don't tell you why a particular package has taken longer.

A change can be a few lines in your repository and still introduce a new permission or a different way of handling user data. Calling it a small update leaves out that part of the story.

I covered the broader publishing changes in Chrome Web Store Reviews Are Changing. For a package currently waiting in the dashboard, I would concentrate on its status and what changed in that specific release.

What I would check before cancelling a submission

Start with the version in the dashboard. Compare it with the version in the ZIP you meant to submit, and note when you submitted it. If you manage several extensions, include the extension ID in your notes. Similar names and several open tabs make it unnecessarily easy to discuss the wrong item.

Next, check the publisher inbox and the dashboard's status details. Google sends rejection and takedown notifications by default; notifications for published or staged items can be enabled on the Account page. If you're relying on email to notice an approval, check that setting. Review notifications

If the extension requires a login or paid access, check the test access you supplied. The dashboard has a Test instructions tab for providing reviewers with the instructions and credentials needed to access those features. Providing test instructions

Write those instructions for someone who has never used the product. Tell them which page to open, what to click and what result to expect. An instruction such as "test the integration" assumes they already understand a feature you may have spent weeks building.

For the next submission, test the release package itself. Google's preparation guide recommends loading the extension locally and checking its features before uploading. It also specifies that the ZIP should contain the extension files with the manifest at its root. Preparing an extension for submission

My preference would be to unpack the ZIP I actually intend to upload into a separate folder and test that copy. A working development directory doesn't tell me whether I left an asset out of the release. I would also check the first-run experience in a separate Chrome profile, where my existing settings can't hide a missing step.

Testing that copy gives me a chance to catch packaging mistakes before users report them, however quickly the store approves it.

Should you cancel and resubmit to speed it up?

I wouldn't cancel a submission solely because it is taking longer than the previous one. I haven't found an official promise that resubmitting the same package moves it through faster.

Google provides cancellation for situations such as discovering a bug after submission. Cancelling returns the submission to draft so you can correct it and submit again. That is a useful option when there is something concrete to fix. Cancelling a review

The distinction matters when you're tired of waiting. Finding a missing file gives you a reason to replace the package. Refreshing the dashboard and disliking the unchanged status doesn't tell you what to improve.

If I discovered a reproducible defect in the submitted build, I would fix it before asking users to install it. Otherwise, I would keep a record of the submission and follow the support route when appropriate.

When to contact Chrome Web Store support

Once the wait exceeds the three-week threshold above, use the developer support link in Google's guidance. Prepare a short report that identifies the package and explains what you need checked.

Here is the message I would send, with the bracketed fields replaced:

```text
Subject: Pending review for more than three weeks: [extension name]

Hello,

Version [version] of [extension name] has been pending review
since [submission date and time zone].

Extension ID: [ID]
Publisher: [publisher name or ID]
Submission type: [new extension / update]
Current dashboard status: [exact status]

This release changes [brief description].
Permission changes: [describe changes, or state none if checked].

Relevant dashboard messages or case IDs: [details, if any].

Could you check the submission and let me know whether you
need any additional information from me?

Thank you.
```

Use a screenshot if it helps show a mismatch between the status and a message you received. Keep test credentials in the designated reviewer fields rather than adding them to public screenshots or forum posts.

The template is deliberately plain. Someone handling the request should be able to identify the submission without first asking which extension, which version or which date you meant.

Plan the release around the version users can install

For a release with a fixed announcement date, I would consider deferred publishing. It lets the review happen before you choose when to make the approved version public. Keep the staging expiry in mind if the release date moves. Controlling publication timing

For an ordinary maintenance update, I would keep a small release log. Record when you submitted it, when it passed review and when you published it. Note whether the release changed permissions or needed a correction. Over time, that gives you something better than remembering the fastest approval and expecting every update to match it.

If users are waiting for a fix, tell them the version number they need. Until that version is available, "submitted for review" is the accurate update to give them.

I like seeing one of my updates appear in the store a few hours after I upload it. It makes maintaining small extensions much less frustrating. I still want the release plan to work when the next submission takes longer.