Reliability report
Built for full rooms
How Quizpedition performs under load, and what we haven't tested yet.
Updated 5 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. We have validated the platform in load testing to 800 concurrent players — the gap between those two numbers is deliberate headroom, not caution about the result.
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 eleven challenges spanning six task types — multiple choice, free text, yes/no, image sequencing, image pairing and hotspots — and read the live leaderboard, exactly as a real attendee would. A separate set of runs added photo answers to the same flow — camera capture, upload to storage, and submission. No app, no install: browser only.
Results
Every join. Every answer. Every leaderboard render.
- Success rate
- 100%
- Submissions verified
- 8,800/ 8,800
- HTTP errors
- 0
- Leaderboard · 500 players
- < 1second
Across repeated runs at 500 players and validation runs at 800: every join succeeded, every answer submission succeeded, every leaderboard render succeeded. Zero HTTP errors. Zero database failures at any scale tested. All 8,800 answer submissions in the 800-player run were verified correct — not merely accepted, but checked against the expected stored result and reconciled through the scoring and display path — and that verification has been repeated on every run since without once coming back short. The live leaderboard has now been rebuilt twice: the first rebuild made it roughly a hundred times faster than our first working version, and the second changed how standings are gathered and sent so the cost no longer climbs with the size of the room, worth about six times again at 800 players. It returns in well under a second at 500 players, across every run we have measured.
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.
Photo answers are validated to 500, not 800.
Photo upload has now been load tested at 100, 200, 300, 400 and 500 concurrent players: every capture, every upload, every submission landing, nothing lost, and upload time flat across the range. That matches the number we support — but it is not the 800 the rest of the platform has been pushed to, because a photo answer adds a file upload per player and we have not yet taken that path to the ceiling. We also know how it behaves when storage does refuse an upload, having seen it in testing: the answer is not recorded at all, the player is told immediately and keeps the photo they already took, and retrying is one tap. No score is ever recorded against a photo that never arrived, and the counts reconciled exactly — as many missing answers as refused uploads, with no partial or orphaned records.
We found a ceiling, and 800 is sitting on it.
Above our supported range the platform degrades rather than failing outright. At 800 players everything still lands — every answer stored, every score reconciled — but answer-submission time reaches the internal budget we hold ourselves to instead of staying comfortably inside it, and repeat runs fall on either side of that line. 500 is where the margin is real, which is why it is the number we support rather than the largest one we could technically print.
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. 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.
info@quizpedition.com →Test log