Steam game review delays: a launch planning guide
Steam game reviews now take up to 12 business days. See what Valve is changing and how indie teams can reduce re-review risk and protect launch plans.
Steam's longer game reviews: how indie teams should prepare
A Steam review that used to take three to five business days can now take up to 12. If you're trying to land a launch on a specific date, that's not just an administrative hiccup - it can throw off marketing, press outreach, launch-day coordination, and even the cash-flow assumptions behind a smaller project.
Valve says it's seen a significant jump in store and page review submissions in recent months. It also says a lot of the added time comes from games that need to be reviewed again. To cut down on repeat submissions caused by basic functional issues, Valve is updating its release checklist. The new requirements include running a build through Steam for at least five minutes, verifying achievements, and confirming the required common redistributables.
For developers, that signals two things. First, review capacity is under pressure. Second, a preventable build problem can add another loop to your process. Below is what Valve announced, what the delay means for launch planning, and how to make a Steam submission easier to review - without treating the checklist like a rubber stamp.
Why are Steam game reviews taking longer?
Valve says the volume of store and page review submissions has risen significantly in recent months. Reviews now take up to 12 business days, instead of the typical three to five days. "Up to" matters here: it's an upper-end estimate, not a promise that every review will land exactly on day 12.
Another big detail is re-review. Valve says much of the delay is tied to submissions that need another pass. Repeat reviews take time from both sides - developers have to prepare and resubmit, and reviewers have to re-check. Even when the underlying fix is small, you still end up with another build, another verification, and another waiting period.
That distinction matters because the right response depends on the cause. You can't control how many other games are in the queue. But you can control whether your build was tested in the same route a player will use, and whether the required features and dependencies are actually in place.
The delay is a planning risk, not a fixed duration
A common mistake is working backward from a public launch date using the older three-to-five-day window. That may have worked when reviews were faster and the team had room for a quick correction. With Valve now pointing to a window of up to 12 business days, your plan has less room for a failed review - or a second submission.
Also, business days aren't the same as calendar days. A 12-business-day window can stretch across more than two weeks depending on weekends and holidays. If review timing sits on your critical path, the calendar impact is bigger than the number alone suggests.
Why re-reviews hit small teams harder
Big studios often have more staff and parallel workstreams to absorb delays. A small indie team usually has the same people building the game, setting up the store page, dealing with press, and handling release operations. When you need a re-review, it competes for that limited attention.
The practical takeaway isn't that every Steam launch will slip. It's that review timing is less predictable than it used to be. Treat it as a real dependency with uncertainty - not a quick formality that can safely wait until the end.
What is Valve changing in the review checklist?
Valve is changing parts of its release checklist to reduce re-reviews for basic functional issues. The focus is on whether your build works in Steam's environment and whether expected setup steps are ready for users.
The first change is especially telling: Valve now requires developers to run the game through Steam for at least five minutes. Valve says it sometimes receives builds that haven't been played through Steam at all. A game might start fine when a developer launches the executable directly, yet behave differently after it's installed and launched through the platform.
It's easy to miss that while you're moving quickly. Local shortcuts and dev setups can hide real differences like install paths, launch configuration, first-run setup, or missing dependency handling. Testing the executable directly proves one route works. It doesn't prove the Steam install-and-launch route will work for a player.
Achievements and redistributables are part of the release path
Valve also calls out achievements and required common redistributables, including DirectX or Visual C++. These aren't decorative. If your game depends on something the user doesn't have, installation or the first launch can fail - or at least act differently than it does on your development machine.
Achievements function as a similar readiness check. If achievements are part of your planned gameplay, they need to be configured and working in the build being reviewed. If something's present in your dev environment but incomplete or unavailable in the submitted release build, you create a mismatch between what the team expects and what a reviewer can verify.
The checklist is the floor, not the finish line
Passing these checks doesn't mean the game is bug-free, polished, or guaranteed to sail through review. Valve's described changes are meant to reduce repeat reviews for basic issues, not replace your own QA.
Think of the checklist as a release gate. Confirm that the basic Steam user journey works before you submit. Then test more broadly based on what your game supports and where the risks are. A five-minute run can catch a missing first-run dependency or a broken launch path, but it can't stand in for testing every level, save/load behavior, controller support, or configuration you claim to support.
How should developers adjust launch plans?
The main planning change is to stop treating store and page review like a near-final administrative step. It should be scheduled as a dependency with a buffer and a clear owner. Valve's stated review time can reach 12 business days, and a re-review can extend the path further. If your launch plan has no slack for either outcome, it's fragile.
Start from the date that matters most: the public launch. Work backward through everything that depends on approval - finalizing the store presence, planning announcements, and prepping launch-day operations. Identify what can run in parallel and what can't. That makes your critical path visible, instead of hiding review time inside a vague "final week" task list.
Separate submission readiness from launch readiness
A build can be ready for review without your full launch operation being ready. And a great marketing plan doesn't mean the build is ready to submit. Track those as separate workstreams so one doesn't create false confidence about the other.
A practical schedule should cover:
- When the review-ready build will be submitted.
- How much time you're reserving for review, using the current longer window instead of the old typical range.
- A correction and resubmission allowance, based on how much risk your team can stomach.
- The latest date when a review outcome can arrive without forcing a launch change.
- Which announcements or commitments depend on that outcome.
This isn't an argument to freeze everything until approval. It's a way to decide what you can safely commit to early - and what should stay conditional. A team with flexibility can accept more uncertainty than one tied to a convention schedule, publisher promises, or a coordinated release.
Choose a launch date based on the cost of being wrong
There's no single buffer-day number that fits every project. A short, low-risk game with a flexible release date lives under different constraints than a title with paid promotion and outside partners.
The "right" buffer depends on what happens if you miss your target - not just how many people are on the team. If changing the date would be expensive, submit earlier and leave time for a potential re-review. If waiting is costly and the release window is flexible, you might accept more risk. Just make that decision deliberately, write down your assumptions, and agree on a trigger for changing the plan - for example, how many unresolved days of review status should cause you to adjust the announcement.
How can you prepare a build for Steam review?
Treat the submission like a player-path test, not just another build upload. Your reviewer should be able to install and launch the game through Steam, get through the initial setup, and reach the core experience without relying on developer-specific steps.
Before submitting, try to use a clean or representative environment where possible. Your dev machine might already have libraries, files, or settings that a typical player won't. The closer your test is to a fresh install, the better chance you'll catch a missing redistributable - or an assumption you accidentally made about local files.
Run a focused pre-submission checklist
At minimum, confirm the items Valve called out:
- Install and launch the submitted build through Steam.
- Play it through Steam for at least five minutes.
- Confirm the expected first-run flow completes and you reach playable content.
- Verify achievements intended for the release build.
- Confirm required common redistributables (like DirectX or Visual C++) are handled correctly.
Then add checks based on your own game. Test the launch options you support, verify save behavior, and make sure the build doesn't depend on files that only exist in your development environment. If you have a launcher, controller setup, or an account flow, include the parts that affect a first-time player.
Make ownership and evidence explicit
Checklist items often fail for a simple reason: everyone thinks someone else handled it. Assign one person to confirm the Steam install path. Assign another to validate dependencies if that's on engineering. Make sure achievements and platform configuration have a clear owner too. In a small team, one person can own multiple items - what matters is that responsibility is visible.
Keep a short record of what build you tested, how you installed it, and what checks you ran. This doesn't have to turn into heavy compliance paperwork. A simple release note or checklist entry gives the team a clear answer when fixes land: what changed, what needs retesting, and whether the submitted build still matches the one that passed internal checks.
Avoid last-minute changes without a retest
A build can pass the checklist and still break later if someone changes the executable, configuration, or dependency handling. The bigger the gap between what you tested and what you actually submitted, the less useful that earlier test becomes.
When changes land late, think about the blast radius. A small text fix might only need a narrow check. But changes to packaging, launch configuration, or dependency handling can affect the install-and-launch path - so plan for a broader retest. It's basic release discipline, and it matters more when another review cycle could cost days instead of hours.
Key takeaways
Plan for the review queue you have, not the one you were used to. Valve says reviews can take up to 12 business days, and repeat reviews are a major source of delay.
- Submit a build that's been installed and played through Steam, not just launched directly.
- Verify achievements and required redistributables before you submit.
- Put review time (and possible correction cycles) on your launch plan's critical path.
- Decide upfront how much review uncertainty your launch date can tolerate.
- Treat Valve's checklist as a minimum release gate, not as a substitute for QA.
Conclusion
Valve's longer review window changes the risk profile of a Steam launch, especially for teams with limited flexibility on a public date. Instead of guessing how fast submissions will clear, focus on what you can control: reduce avoidable re-reviews and make the remaining uncertainty visible in your schedule.
Test the actual Steam install-and-launch path. Confirm achievements and dependencies. Assign clear ownership for the release checks. Then treat review time as a real production dependency - with a buffer that matches the cost of missing your target. That won't change the queue, but it does help your team make a more defensible launch decision.