Reliability report
Built for full rooms
How Quizpedition performs under load, and what we haven't tested yet.
Updated 29 September 2026
Event technology fails in public. If it breaks, it breaks in front of your client's three hundred guests, and the producer who recommended it wears it. So before asking any agency to put Quizpedition in front of a real room, we went looking for the breaking point ourselves.
What we support
Supported to 500. Validated to 800.
Quizpedition is supported for events of up to 500 simultaneous players, and validated in load testing to 800 concurrent players. 500 is not a rounded-down 800. It is where the platform is most efficient: each player costs us about 5 milliseconds of system time at 500, and about 12 at 800. We support the number where the margin is real.
What we measured
Real infrastructure, real player flows.
Testing was run with k6, an industry-standard load testing tool, against the same Railway, Postgres and Cloudflare infrastructure that serves production. Each simulated player joined with a unique nickname, played thirteen challenges spanning seven task types — multiple choice, free text, yes/no, image sequencing, image pairing, hotspots and photo answers — and read the live leaderboard, exactly as a real attendee would. Photo answers are part of every run: camera capture, upload to storage, and submission. No app, no install: browser only.
Every run drives two games at the same time, one individual and one team game split across five teams, so isolation between concurrent games is tested rather than assumed. The test database is reclaimed before every run, so no measurement is inflated by leftovers from the run before it.
Results
Every join. Every answer. Every leaderboard render.
- Success rate
- 100%
- Submissions verified
- 10,400/ 10,400
- HTTP errors
- 0
- Leaderboard · 500 players
- ~0.5second typical
Across runs at 300, 500 and 800 concurrent players: every join succeeded, every answer submission succeeded, every leaderboard render succeeded. Zero HTTP errors. Zero database failures at any scale tested.
Correctness is checked against the database rather than counted from the outside, and it is checked at the top of the range rather than the middle. In both 800-player runs, all 800 players completed all thirteen challenges with none partial, and all 10,400 answer submissions were verified against the expected stored result and reconciled through the scoring and display path. Zero wrong answers. All 1,600 photo answers approved and filed in permanent storage, none left stranded. No player's progress linked to another game's challenge. The same verification passes at 500, and has passed on every run since we began publishing these numbers.
The live leaderboard has been rebuilt twice since our first working version, and returns in about half a second at 500 players — 441, 495 and 523 milliseconds across three of our four most recent runs at that size. The fourth read 1.2 seconds. We publish the outlier because a number quoted without its worst sample is not a measurement.
On speed, the honest number: at 500 players the slowest joins take about two and a half seconds, and the slowest answer submissions between two and three. Nothing fails and nothing is lost, but a join should be faster than that, and it is the next thing we are working on.
What these tests do not prove
Four things, stated plainly.
Because a supplier who only publishes their good numbers isn't telling you anything useful.
We found a ceiling, and it is our database.
Above our supported range the platform degrades rather than failing outright. At 800 players everything still lands and everything still reconciles — both runs verified in full, every one of the 10,400 answers correct. What changes is speed. Every request that touches our database slows by between two and a half and nearly four times: joins, challenge loads, answer submissions, the leaderboard. Photo upload, which goes to Cloudflare rather than to us, does not change at all. That pattern rules out any single feature and points at one thing — shared database capacity. It is a known limit with a known cost to raise, and we have not raised it, because no client has yet asked for a room of 800. At 500 the same work costs us less than half as much per player, which is why 500 is the number we support rather than the largest one we could print.
Every test ran our own games, on their own.
The two games in each run share a database, so we know games don't interfere with each other. What we have not tested is that database carrying several clients' events at the same time. Since the ceiling we found is database capacity, that is the honest open question: a 500-player room on a quiet evening is proven, and a 500-player room on an evening when three other agencies are also running games is not yet.
These were bursts, not full-length games.
The runs prove the platform absorbs peak concurrency, including the moment an entire room scans the same QR code at once, but they complete in under two minutes rather than over twenty. A sustained twenty-minute soak test is next on the list.
These were simulated clients, not real phones.
No five-year-old Android, no congested hotel Wi-Fi, nobody backgrounding their browser mid-game and coming back. No load test catches those — only a real room does, and we are running one with a live audience before any client event.
Ask for the numbers
You can have the raw output.
If you are evaluating Quizpedition for a client event, ask and we will send the raw test output — all of it, including the runs where we found the limit.
One thing to know before you read it. At 800 players the test tool exits with an error code, because our own latency target was exceeded. Every request in those runs succeeded and every database check passed. That error is us holding ourselves to a budget, not the platform failing.
info@quizpedition.com →Test log