12 Free Steam Pre-Release Review Checks Before You Mark Ready - 2026

If you searched steam pre-release review checks after Valve’s November backlog update, you already have a what-changed map and a Stop on 3–5 day launch folklore. What was missing is a numbered free kit: twelve pass/fail checks before anyone clicks Mark as ready and starts a re-review loop.

Valve’s Updates to the Pre-Release Review Process says reviews are running behind at up to 12 business days, that much of the delay comes from re-reviews, and that a tighter checklist helps builds pass the first time. The items they called out include running the game through Steam for at least five minutes, specifying common redistributables, verifying achievements and Steam Cloud when you claim them, and categorizing at least five gameplay screenshots. Standing rules still live on Review Process and Release Process.

This listicle owns the pass/fail preflight. It is not the policy map. It is not the calendar refusal. It is not the buffer worksheet. It is not Next Fest LIVE/OPT-OUT or Winter Sale discount locks. Run the kit, then decide whether Mark as ready is honest.

Why this matters now

Studios missed Early Access and full launches while the queue sat at multi-week waits — The Verge documented that pressure, and Valve answered with a backlog number plus a first-pass checklist. A re-review does not reset the world to “try again tomorrow.” It puts you back in a queue that partners are already planning at 12 business days. The cheapest fix is to fail the kit on your own machine before Valve fails it for you.

Direct answer: Do not Mark as ready until checks 1–12 are green on the same build ID you uploaded. Steam Play for five minutes on an older depot does not count. Explorer double-click does not count. Five concept-art capsules do not count as gameplay screenshots. If any row is red, fix it, re-upload if the binary changed, and replay Steam before you mark ready again.

Who this list is for

Time: 30 minutes to read. First full pass on a near-final default branch: 2–4 hours, longer if Cloud or achievements were never wired.
Honest limit: Steamworks announcement + Review Process + Release Process win if this page drifts. Five minutes of Steam Play is a functional smoke, not a QA pass. Adult-content and some edge reviews can still run long even when the kit is green. The buffer worksheet owns the calendar math; this page owns the gates.

Non-repetition

Four-check minimum (forty minutes)

If the team only has one sitting before a producer wants the button, these four still block the worst re-reviews:

Do not treat the four-row shortcut as the whole kit. Achievements, Cloud, store order, and the Mark-ready latch still fail real submissions. Use the shortcut only to stop a same-day panic click.

Selection criteria

A row is in this list only if it is:

1. Free — Steamworks partner tools you already have, no paid QA vendor.
2. First-pass — Valve named it in the November checklist, or standing Review / Release Process already treats it as a reject cause.
3. Observable — pass or fail on a build ID, not a vibe.
4. Differentiated — not a rewrite of the what-changed article and not a launch-date sermon.

Out of scope: wishlist analytics, Next Fest branch labels, discount percentages, Deck Verified badges, and “is the game fun.” Those are other URLs.

Check 1 — Store presence is on the release path before build review

Pass: Someone can point at the app landing page and say whether store presence is already in review or approved, using the order on Release Process.

Fail: The build is marked ready while the store page is still a draft, the capsule is a placeholder, or nobody knows which checklist is which.

Steam separates store review and build review. The classic flow completes store presence, marks that ready, and only then submits the build. Both must be approved before you release. Marking a build ready on an empty store page does not skip the store track. It creates two queues and a confused producer.

How to pass

1. Open the app in Steamworks.
2. Finish the store presence items you can finish (description, capsules, screenshots, pricing intent, platforms).
3. Note the store state in one line: DRAFT, IN_REVIEW, or APPROVED.
4. Only schedule build Mark as ready when that line is not DRAFT unless your partner manager has a written exception. This kit does not invent exceptions.

Time: 20–60 minutes if the page is close; days if capsules are missing.
Honest limit: Store review has its own timing. This check only stops you from pretending the build button replaces the store button.

Check 2 — The build ID you will ship is written on the card

Pass: A single build ID (or depot set + build number Steamworks shows) is copied into the scorecard before any playtime test.

Fail: “Latest on default” with three uploads this afternoon, and nobody knows which one review will open.

Playtime, launch options, and redistributables attach to a build. If you upload again after the smoke, the smoke is stale. Write the ID first. If you upload a fix, cross out the old ID and start checks 4–8 over.

How to pass

1. Upload to the branch you intend to submit (usually default for the release candidate).
2. Copy the build ID from the Steamworks builds list.
3. Put it in the scorecard field BUILD_ID.
4. Refuse Discord messages that say “it’s up” without that ID.

Dev note: steamcmd upload logs and the partner site can disagree for a few minutes. Wait until the site shows the build before you play it. If the upload failed, Help is the place for config errors — do not Mark ready on a build that never finished.

Check 3 — Launch options and depots match the store feature list

Pass: The default launch option starts the game players will buy, and every store feature you list (controller, cloud, multiplayer, trading cards later, language) is either true on this build or removed from the store text.

Fail: Review opens a debug launcher, a missing depot, or a store page that promises co-op the build does not contain.

Review Process already expects the build to match what the store says. The November update tied that class of miss to re-review load. Feature mismatch is not a copy edit you can do after approval without thinking — it is a reason the first pass fails.

How to pass

1. Read the store “features” and the first screen of the description out loud.
2. Launch once with the default launch option, not your artist’s custom one.
3. If a feature is unfinished, delete it from the store draft before review.
4. If you need a second launch option (DX11 fallback, tools), label it so it is not the default.

Honest limit: This check does not design your game. It stops the store from advertising a binary you did not submit.

Check 4 — Five minutes through Steam on this build ID

Pass: A Steam client account that can see the build has at least five minutes of playtime after this build was set live on the branch, launched from the Steam library (or the partner play command), not from Explorer.

Fail: The team double-clicked the exe, or reused last week’s playtime from build N-1.

This is the checklist item Valve called out by name. The announcement’s practical reading, already mapped in the what-changed article, is: playtime should fall within the past seven days or since the last build if that build is older than the window. A fresh upload resets the useful window. Stale playtime is how “the checklist looked green” becomes a re-review.

How to pass

1. Install or update the app in Steam so the client has BUILD_ID.
2. Launch from Steam.
3. Reach an interactive state (menu that accepts input, or gameplay). A crash-to-desktop in second ten is a fail, not a five-minute run.
4. Stay in the session until the client shows about five minutes. Alt-tabbing to zero the process does not count.
5. Quit cleanly through your normal exit path.

Time: 10–20 minutes including install.
Honest limit: Five minutes will not catch a soft-lock at minute forty. It catches “will not start,” wrong depot, and missing launch option — the failures that generate re-reviews.

Check 5 — Playtime has reflected before you trust the checklist

Pass: After quit, you waited and the Steamworks release checklist (or the playtime line you use) shows the new session, not yesterday’s.

Fail: You clicked Mark as ready thirty seconds after Alt-F4 because the local session “felt like five minutes.”

Valve’s own note on this item is that playtime can lag. Treat reflection as part of the check. If the line does not move, do not argue with the UI by marking ready. Replay or wait, then look again.

How to pass

1. Exit the game.
2. Note the clock.
3. Refresh the checklist after a short delay (minutes, not a coffee-tomorrow delay unless the client is broken).
4. Confirm the playtime is tied to the current build, not a prior one. If you cannot tell, assume fail and replay on BUILD_ID.

Beginner trap: Playing a public demo branch or an old playtest branch updates a different build. The scorecard’s BUILD_ID is the only branch that matters for this Mark as ready.

Check 6 — Common redistributables are specified, or explicitly none

Pass: The install configuration names the common redistributables the game needs (DirectX, Visual C++, .NET, XNA, and similar), or a written line says none because you verified a clean machine.

Fail: Blank redistributable settings and a game that crashes on a PC without your engine’s runtime.

The November checklist calls this out because reviewers and players are not your dev box. “Works on my machine” is usually a runtime you installed years ago.

How to pass

1. List runtimes your engine actually needs for a customer install. Unity, Unreal, Godot, and custom C++ answers differ — check the engine export docs you ship with, not a blog guess. Guides are the on-site ladder for engine packaging; this row only asks you to declare the result in Steam.
2. Set those redistributables in Steamworks, or document REDIST=NONE after a clean-profile launch.
3. If you are unsure, fail the check. Guessing “none” and crashing in review is a re-review.

Company note: A publisher diligence zip should include the redistributable line next to BUILD_ID. Blank is not “we’ll see.”

Check 7 — Achievements match the claim, or the claim is off

Pass: If the store says the game has Steam achievements, you can unlock at least one from normal play on BUILD_ID, and the achievement list in Steamworks is not a pile of NEW_ACHIEVEMENT_1 placeholders you intend to ship. If the game does not ship achievements at launch, the store does not say it does.

Fail: Achievements are configured, none fire, or the store advertises them while the binary has zero calls.

How to pass

1. Read the store line about achievements.
2. If yes: trigger one easy unlock on the review build, confirm it appears on the client overlay or the partner stats view you use.
3. If no: remove achievement language from the store draft.
4. Do not archive or reshuffle live achievement IDs as part of this pre-release pass unless you already have a player-safe plan. That is a different problem from “does the first unlock work.”

Time: 15–45 minutes when the API is already integrated; days when it is not. If it is not integrated, you are not ready to claim achievements. Uncheck the claim.

Honest limit: One unlock does not prove every stat. It proves the pipe is not dead, which is what first-pass review is trying to see.

Check 8 — Steam Cloud matches the claim, or the claim is off

Pass: If you enable Steam Cloud, a save written on BUILD_ID syncs (or the Cloud UI shows the file) and a second launch sees it. If you do not support Cloud, it is off and the store does not promise it.

Fail: Cloud checkbox on, save path wrong, quota zero, or a store bullet that says “cloud saves” while the toggle is off.

How to pass

1. Confirm the Cloud toggle matches the store sentence.
2. If on: write a save, exit cleanly (check 4’s quit path), confirm the remote file, launch again, load.
3. If the path is wrong, fix the auto-cloud byte paths or the Cloud API calls before Mark as ready. A review note that says “cloud does not work” is a re-review, not a patch-later joke, when you advertised it.

Honest limit: Two machines are better than one. One machine still catches a total misconfiguration. Do not skip the row because “we’ll test Cloud after launch.” Launch review is when the claim is judged.

Check 9 — At least five screenshots are categorized as gameplay

Pass: The store screenshot set includes five or more images categorized as gameplay, from the build you are actually shipping, readable at capsule size.

Fail: All images are logos, concept art, menus, or one gameplay shot duplicated.

The announcement sets five gameplay as the bar. Standing review rules already wanted real screenshots. Menus can exist in the set. They do not replace the five.

How to pass

1. Capture from BUILD_ID, not from a trailer render.
2. Show play: combat, puzzle, exploration, management — whatever the game is.
3. Categorize each gameplay shot as gameplay in the store admin, not “other.”
4. Check that text in the shot is legible. A blurry 4K downscale that reads as noise fails the spirit of the check even if the count is five.

Creator note: Key art still belongs in capsules. It does not fill this row. If you only have key art today, the check is red.

Check 10 — Capsules and the short description describe this build

Pass: A stranger can read the short description and the capsule text and predict the first five minutes you just played in check 4.

Fail: The capsule sells a mode, character, or platform that is not in BUILD_ID.

This is the store-clarity half of the same mismatch as check 3. Screenshots can be honest while the capsule still lies. Reviewers read both.

How to pass

1. Paste the short description into the scorecard.
2. Strike any sentence you did not see during the five-minute Steam session or that is not implemented behind a menu you can open.
3. Confirm library capsule and header do not show a character you cut.
4. If you need a “coming soon” feature, label it as not in the launch build.

Time: 20 minutes when copy is close.

Check 11 — The default branch is the branch review will open

Pass: You know which branch is submitted for review, the build ID on that branch is BUILD_ID, and passworded or beta branches are not the only place the game runs.

Fail: The good build is on qa and default still has last month’s crash.

Partners often test on private branches and then mark the wrong one. Write the branch name next to the build ID: BRANCH=default or whatever you truly submit. If release process for your app uses a different branch, the scorecard must name it. “The programmers know” is a fail.

How to pass

1. Set the release candidate live on the branch you will submit.
2. Launch that branch from Steam (check 4).
3. Lock uploads to that branch until Mark as ready is done, or restart the kit when you upload.

Dev verification: After any steamcmd push, re-read the build ID. A silent second upload is the most common way check 4 becomes a lie.

Check 12 — Mark as ready is a recorded latch, not a vibe

Pass: Checks 1–11 are green on one scorecard, an owner initials the card, and only then someone presses Mark as ready for build review. The public announce plan follows the 3–5 day Stop: no hard consumer date that assumes a 3–5 day clearance.

Fail: The button was pressed to “get in queue” while three rows were red, or a tweet already promises Friday.

Getting in queue with a broken build does not save time. It spends a review slot and comes back as a re-review, which Valve said is a major reason the queue is long. The latch is the point of the kit.

How to pass

1. Fill the scorecard below.
2. Any red row blocks the button.
3. Owner writes name, date, BUILD_ID.
4. Mark as ready.
5. Tell marketing the state is IN_REVIEW, not LAUNCH_FRIDAY, until the build shows approved. Put the day on the buffer worksheet. The Stop is why that sheet refuses a 3–5 day plan.

Scorecard you can paste

Copy this into the launch ticket. One row, one owner. Do not merge rows to “look green.”

MARK_READY_OK only when every row is PASS. Otherwise the status is BLOCKED and the button waits.

Monday sequence (two to four hours)

Use this order so you do not replay Steam three times.

1. Check 1 — store state. If the page is an empty draft, stop and finish store work. Build review will not forgive a blank store.
2. Check 2 and 11 — upload, write BUILD_ID and branch. Freeze uploads.
3. Check 6 — redistributables before you call the install “done.”
4. Check 4 and 5 — five minutes through Steam, then wait for reflection.
5. During that session, do check 3 (default launch option) and start check 7 and 8 if those features exist.
6. Check 9 and 10 — screenshots and copy from what you just played.
7. Check 12 — latch, then Mark as ready.
8. Tell the channel the date is a window, using the Stop, not a folklore Friday.

If step 4 fails (crash, wrong depot), fix, new build ID, return to step 2. Do not recycle the old playtime.

Worked fail (why re-reviews happen)

A two-person team uploads build 42 on Monday, plays build 41 from a desktop shortcut for “like ten minutes,” leaves redistributables blank, uploads five key-art images, and Marks ready so the trailer tweet can say Friday. Review opens build 42, the game crashes without VC++, screenshots are not gameplay, and the store promises Cloud that was never toggled. The build comes back. The second review sits in the same backlog Valve measured in business days, not hours.

The kit on build 42 would have failed rows 4, 6, 8, and 9 before the button. That is the whole product of this page.

What this kit will not do

After the first approval, Review Process still describes updating the build without sending every patch back through review. That privilege is for after you pass once. It is not a reason to skip the first kit.

Company diligence

Ask for the scorecard in the launch zip, not a slide that says “Steam review: 3–5 days.”

• BUILD_ID, branch, owner, date.
• Redistributable line.
• Screenshot count categorized as gameplay.
• Achievement and Cloud each marked TESTED or NOT_CLAIMED.
• Public copy that does not promise a day inside the backlog window.

If a publisher contract assumes clearance in one week, that is a legal conversation. It is not a reason to Mark ready on a red scorecard. Pair the zip with the policy language in the what-changed article.

Creator paste (Discord)

Steam pre-release kit before Mark as ready: store not draft, build ID written, five minutes through Steam on that build, playtime reflected, redistributables set or none, achievements and Cloud match the store, five gameplay screenshots, capsule matches the binary, owner initials. Then we wait on Valve’s backlog — we do not promise Friday.

Paste targets live in real communities such as the servers listed in the 25 Discords resource. Do not invent an on-site community page.

Common mistakes

Key takeaways

• Steam pre-release review checks are a first-pass kit so you do not buy a re-review inside a 12 business day backlog.
• Valve’s November update names Steam Play (≥5 minutes), redistributables, achievements, Cloud, and five gameplay screenshots.
• Playtime must be on the build ID you submit, then reflected on the checklist.
• Store presence and build review are different tracks (Release Process).
• Feature and capsule text have to match the binary reviewers will launch.
• A four-check panic pass (ID, Steam Play, redistributables, screenshots) is the minimum, not the whole list.
• MARK_READY_OK requires all twelve rows. Anything red is BLOCKED.
• Five minutes is a launch smoke, not full QA.
• Approval timing is still a backlog problem — use the 3–5 day Stop for dates.
• A new upload invalidates the Steam Play row. Start that row over.
• The what-changed map explains why the kit exists. This page is the card you fill.
• Outbound authority stays on the Steamworks announcement plus Review Process. If they edit the checklist, edit your card the same day.

FAQ

What are the Steam pre-release review checks that matter in November 2026?

Run the game through Steam for at least five minutes on the build you submit, set common redistributables, make achievements and Steam Cloud match what you claim, and publish at least five screenshots categorized as gameplay. This page turns those items plus store order, build ID, and a Mark-ready latch into twelve pass/fail rows. Source: Steamworks announcement.

Does playing the exe for five minutes pass the checklist?

No. The update asks for playtime through Steam. A desktop shortcut can pass your local smoke and still fail review because the depot or launch option is wrong.

How long should we wait after quitting before Mark as ready?

Until the checklist playtime line reflects the session. The announcement warns that playtime can lag. Marking ready in the same minute you quit is how stale or missing playtime slips through.

What if we do not have achievements or Cloud?

Do not claim them. Checks 7 and 8 pass when the store and the toggles agree that the feature is absent. They fail when the page promises a feature the build does not have.

How many gameplay screenshots does Steam want now?

At least five, categorized as gameplay, from the build you are shipping. Concept art and menus can sit beside them. They do not replace the five.

Will a green kit make review finish in three to five days?

No. Valve said they still aim for a typical 3–5 day test and that they are behind at up to 12 business days, with re-reviews as a major cause. A green kit avoids the re-review. It does not shrink the published backlog by itself.

We uploaded a hotfix after the five-minute play. Are we still good?

No. Checks 4, 5, 7, 8, and 11 bind to BUILD_ID. A new upload needs a new ID and a new Steam session before Mark as ready.

Where should marketing read the date rule?

On Stop Planning Steam Launches on 3-5 Day Review After November Backlog - 2026. This listicle only blocks the button. It does not pick the announce day. Seasonal sale locks stay on the Winter Sale prep worksheet.

Conclusion

Mark as ready is a queue ticket. In November 2026 that queue is long enough that Valve published 12 business days and asked partners to stop failing the easy stuff. The twelve checks are the easy stuff: the right build, launched from Steam, with runtimes, claims, screenshots, and store text that match, latched by a named owner.

Fill the scorecard once on the release candidate. If a row is red, you still have your afternoon. If you skip the card, you may spend the next review cycle explaining a crash that a clean PC and a five-minute Steam session would have shown today.

Bookmark the card, keep the Steamworks announcement next to it, and treat Review Process as the rulebook when a row here feels ambiguous. Then wait. The button is not the launch.