Is a two-hour refund window enough to judge a game?
We logged 1,800 of our own refunds. More than half of the problems show up within 40 minutes, but performance problems take 96 minutes on average.
Steam's refund rule is 14 days from purchase and under two hours played. The rule has been used as a demo window for a decade, and almost nobody asks whether two hours is enough to learn what a game actually is.
We went through 1,800 refunds from our own purchases over 24 months, sorted them by reason, then looked back at playtime on each record. The sample is not rigorous. It is our own buying behaviour and it carries selection bias. It is still enough to show a pattern.
How fast the problem appears
| Refund reason | Share | Median time to spot it |
|---|---|---|
| Would not start, or frequent crashes | 23% | 12 minutes |
| Performance below acceptable | 31% | 74 minutes |
| Gameplay or content not as expected | 28% | 38 minutes |
| Controls or UI unusable | 12% | 26 minutes |
| Other | 6% | 55 minutes |
Median minutes to spot the problem. The dashed line is the refund window.
By the median, 54% of problems are confirmed within 40 minutes. Those refunds are decisive, and the length of the window does not matter to them.
The group that gets caught is the 31% with performance problems: 74 minutes at the median, 96 on average. Most games spend the first 30 minutes in tutorials and cutscenes, with simple scenes and a flattering frame rate. By the time you reach the open world or the first large fight, more than an hour is gone.
Our data has a cluster of records between 1:50 and 2:05, people who found the problem right at the line and ran out of window.
The problem is how we test
The window is fixed. How you use it is not.
Most people, ourselves included early on, follow the tutorial. That is exactly the best-optimised part of the game: small scenes, few NPCs, pre-rendered cutscenes. Judging performance there means testing the heaviest scenes with the lightest load.
We changed to running a stress test at the start.
First 20 minutes, skip whatever can be skipped. Go straight to the most complex scene: an open-world town, a multiplayer map, the fight with the densest effects. Do the tutorial later.
Open the frame-time graph, not the frame counter. A regular sawtooth in the curve tells you more about stutter than an average does. Both NVIDIA and AMD drivers ship the overlay.
Watch the 30-minute mark. VRAM leaks, memory leaks and thermal throttling usually need time to show. Some games are perfect for 20 minutes and start dropping frames at 40.
Do not conclude in the first hour. Story-driven games especially: the first 90 minutes may be all setup. The question there is whether you want to know what happens next. Fun is a separate matter, and it can arrive late.
What two hours is good for
It works better as a window for ruling games out. Evaluating a game takes longer than that.
Two hours is enough to rule out: it will not run, it visibly stutters, the controls are unacceptable, the subject does not interest you at all. Those are hard rejections, and they account for 66% of our sample.
Two hours is not enough to judge: where the story goes, how much content sits in the late game, whether post-launch support holds up, whether the multiplayer survives. Those need someone else's long-term review, or a sale.
One more note. The looseness of the rule is quietly tolerated by publishers because it shifts the cost of a demo onto developers, and it hurts independent studios most. Our own policy now is to keep any indie game that is not a hard rejection. Two hours is survival for them and the price of a meal for us.
