Beta Testing Checklist: How to Run a Closed Beta for Your Game

This beta testing checklist is for indie developers who are about to hand a nearly finished build to a limited group of outside players. It covers how to run a closed beta from the week before launch to the thank-you post at the end, with copy-paste messages for each stage. Work through it in order and tick items off; every step exists because a real beta somewhere went sideways without it.

A closed beta is not a first playtest. If you are still asking "is this fun?", you want a smaller, earlier round (see how to run a playtest). If you are not sure which stage you are at, our playtest vs beta test guide lays out the difference. Use this checklist when the game is content-complete or close to it and you need to find bugs, balance problems and confusing moments before launch.

Before you invite anyone: the planning checklist

Most closed betas that fail do so before the first tester opens the build. The problems are a fuzzy goal, a feedback form that doesn't work, or no plan for what happens after week one.

• Write the one question this beta must answer. "Is the late-game economy balanced?" or "Does the game run on five-year-old laptops?" is a goal. "Get feedback" is not. Flockbay's closed beta guide makes the same point: write down the question first, then pick testers and dates to fit it.
• Write 3 to 5 exit criteria. These tell you when the beta did its job. Examples: zero crash reports on the last build for 72 hours, median session over 30 minutes, fewer than 10% of testers stuck at the same spot, every blocker fixed.
• Set start and end dates and publish them. Two to three weeks suits most indie betas. A fixed end date also solves the "do I revoke keys from quiet testers?" problem later. On r/gamedev, the most practical advice on unresponsive testers was to time-limit the test and say so at the start, rather than taking access away mid-test.
• Decide what is out of scope. List what you already know is rough (placeholder audio, missing achievements, unfinished art) so testers don't spend their energy reporting it.
• Decide how many testers you need. A few dozen is enough for a story or puzzle game where you will read every report. Balance, matchmaking and server load need hundreds or more. Our how many playtesters guide has numbers by goal. Expect a big share of sign-ups never to play, so invite more than your target.
• Pick a single place for bug reports and a separate place for opinions. Bugnet's beta guide calls scattered Discord messages and loose Google Form replies the point "where most indie betas fail". Bugs go to one form or tracker. Feel, difficulty and pacing go to a separate channel or survey.
• Name who triages, and when. Even if it is just you: a fixed 30 minutes every morning to read, deduplicate and tag reports.

Build readiness checklist

Testers forgive rough edges. They do not forgive a build that won't launch or a feedback button that eats their report.

• Fresh install test on a clean machine or device. Not your dev machine. Install from the exact link or key testers will get.
• Version number on the main menu or HUD. Every report needs it, and testers can't report what they can't see.
• An in-game feedback key or button. One r/gamedev developer copied Subnautica's F8 feedback form for their closed beta and recommends every game do the same. That same developer then lost the first 36 hours of feedback because the form broke after a late change. Submit a test report from the final build yourself, then check it arrived.
• Crash reporting turned on. Use your engine's crash reporter or a bug tool that captures system info automatically. At minimum, tell testers where the log file lives.
• Basic event logging. Game start, quit, level or chapter reached, death. This is how you find out where people stopped without asking them.
• A save system that survives updates, or a clear warning that it won't. Wiped saves mid-beta are a fast way to lose testers.
• Known issues list written. It goes in the welcome message.

Distribution checklist by platform

Pick one way to get the build out and know its limits before you announce anything.

Steam

Steamworks documents two routes for closed testing. Steam Playtest is a free, separate app linked to your main game. Players sign up from your store page, access is granted in batches picked at random from the sign-ups, playtime and reviews don't touch your main game, and players can still wishlist and follow the main app. Release override keys on your main app suit a confidential test where you run your own NDA. Valve caps these at 2,500 keys per app and warns that players who accept a key are not under any NDA with you unless you set one up.

• Playtest app created, capsule art uploaded, build in the depot
• Sign-ups turned on, or keys generated and labelled by batch
• Country limits set if your servers need them
• Plan for closing: turn off sign-ups, set the playtest to Not Playable, and announce it yourself

Full setup is in our Steam playtest setup guide.

itch.io

A Restricted page plus download keys or a password works well for PC and browser builds. Step-by-step setup, including butler for updates, is in our itch.io playtest guide.

iOS and Android

On iOS, TestFlight lets you invite up to 10,000 external testers, and the first build for external testers goes through TestFlight App Review, so add a buffer of a few days before your start date. Each build expires after 90 days. Our TestFlight beta testing guide covers groups, public links and review times. On Android, a Google Play closed test is the usual route, and new personal developer accounts must also meet the 12 testers for 14 days rule before production; see our Google Play 12 testers guide.

Recruiting checklist

• Start with people who already care. Your Discord, newsletter, wishlisters and past playtesters.
• Add strangers who play your genre. People who picked your game because it looks like something they enjoy give feedback your friends can't.
• Mix experience levels. A core of experienced genre players who will push your systems, plus fresh players who show you where newcomers get lost.
• Cover your hardware. Ask for specs at sign-up. Make sure low-end PCs, older phones and the Steam Deck are represented if you plan to support them.
• Trade tests with other developers. A playtest swap with a dev in a similar genre gets you careful testers who know what useful notes look like.
• Keep a waitlist. When testers go quiet, you will want a second batch ready to invite.

Other places to find testers are collected in how to find playtesters and where to post your game for feedback.

Launch day checklist

1. Send the welcome message (template below) to the first batch only, not everyone.
2. Watch for install problems in the first two hours. If several people hit the same wall, pause invites and fix it.
3. Confirm the first reports are arriving in your tracker or form.
4. Post a short "beta is live" message in your community channel with dates and the known issues link.
5. Invite the next batch once the first one is stable.

If your logs show people quitting inside the first few minutes, fix that before anything else; our game onboarding playtest guide covers what to watch in the first 10 minutes.

Welcome message template

Thanks for joining the [Game] closed beta. It runs from [date] to [date]. What we want to learn: [your one question, in plain words]. Please focus on: [2 or 3 areas, e.g. the first hour, the crafting menus, performance on older PCs]. Already known, no need to report: [list]. Report bugs: press [key] in game, or use [form link]. Include what you were doing, what happened and what you expected. A screenshot or clip helps a lot. Everything else (too hard, boring, confusing, loved it): [channel or survey link]. We'll post a changelog with every build so you can see what your reports changed.

During the beta: the weekly loop

The pattern that keeps a beta alive is simple: reports come in, fixes go out, and testers can see the connection.

• Triage daily. Confirm each report, tag severity (blocker, major, minor, polish), merge duplicates and reply to the reporter. A short "thanks, reproduced, fixing" keeps people reporting.
• Treat clusters as the signal. Bugnet's closed alpha guide suggests fixing every bug that three or more testers report, even if each report looks minor. The same logic applies to confusion: if five people ask how to open the map, the map is the problem.
• Ship at least one update a week with a changelog. Name the bugs fixed and, where testers agree, credit them.
• Ask specific questions at set points. A short survey after the first hour and another at the end beats an open "any thoughts?". Our playtest survey questions guide has ready-made sets.
• Watch behaviour, not just opinions. Where do sessions end? Where do people die or quit? What do they never find? Your event logs answer these.
• Expect drop-off and plan for it. A dev on r/IndieDev described 30 testers sending a wave of great reports, then nobody playing the update. Replies agreed this is normal: most volunteers play once or twice. What helped was making each update meaningful enough to replay, keeping messages short and occasional, and building a small core group of invested testers. Invite your next batch instead of chasing the quiet ones.
• Keep messages to testers rare and useful. One update post per build. No daily pings.

Bug report fields

Whatever tool you use, every bug report should capture:

• Build version
• Platform, device and OS
• What the tester was doing (steps)
• What happened
• What they expected
• How often it happens (once, sometimes, every time)
• Screenshot, clip or log file

Turning vague notes into fixes

Beta testers will still send notes like "the combat feels off". When that happens, ask one follow-up about a specific moment: "Which fight? What did you try, and what did you expect to happen?" Our vague playtest feedback guide has a full set of follow-up prompts.

Closing the beta checklist

• Announce the end a few days ahead. Remind testers of the last day to send feedback and link the final survey.
• Close access cleanly. On Steam, turn off sign-ups and set the Playtest to Not Playable; Steam does not email players when it closes, so tell them. On TestFlight, expire the build when you are done, because Apple notes that testers can keep using an unexpired build even after the game is on the App Store.
• Run the final survey. Overall rating, would they buy or recommend it, the best and worst moment, and what would stop them finishing.
• Check your exit criteria. If they are not met, extend with a clear new end date rather than drifting.
• Write a one-page summary. Top issues fixed, issues deferred, and decisions made. Our playtest report template works for betas too.
• Thank testers publicly. Share what the beta changed. Credits in the game or on the store page are a nice touch if you promised them.
• Keep the list. Ask who wants in on the next test or launch news. This is your best tester pool for the next game.

Closing message template

The [Game] closed beta ends on [date]. Thank you. You sent [N] reports and we fixed [the biggest few things, in plain words]. One last thing: this 5-minute survey [link] shapes what we fix before launch. Want early access to future tests? Reply here or join [list].

Common closed beta mistakes

• Inviting everyone on day one. You can't fix a launch-blocking bug for 500 people at once. Batch invites.
• No version number on screen. Half your reports become unusable.
• Untested feedback path. Submit a report from the final build before announcing.
• Friends only. Friends are kind and already know how your game works. You need people who don't.
• Testing too early. If the core loop is still changing, run small playtests first. A beta is for polish and stability, not for deciding what the game is.
• No end date. Open-ended betas drift, testers wander off, and you never get a clear "done".
• Ignoring silence. No reports on a feature can mean nobody found it. Check your logs.

Getting reviews from players outside your circle

The hardest checklist item for most indies is finding players who don't know you and will actually send something back. On Get Playtests you can post your beta for free with your build link (itch.io, Steam, TestFlight and Google Play links all work) and the focus areas you care about. Players pick games they want to play, then send written, video or livestream reviews against your focus areas. There's no credit card, and you can show the build link only to reviewers who have claimed your playtest, which suits a closed beta. A brand-new developer's first posting may wait until one of their own reviews of another game is approved; that is what keeps reviews flowing for every game on the site, and reviewing someone else's beta is a good way to see what useful notes look like.

Quick checklist

• One question and 3 to 5 exit criteria written
• Dates set, out-of-scope list written
• Fresh install tested, version on screen, feedback button tested end to end
• Crash reporting and basic event logging on
• Distribution route chosen (Steam Playtest or keys, itch.io Restricted, TestFlight, Play closed test) with its limits checked
• Testers recruited across experience levels and hardware, waitlist ready
• Welcome message sent to batch one
• Daily triage, weekly build with changelog, surveys at set points
• End announced, access closed, final survey sent
• Summary written, testers thanked, list kept