RESOURCES

Game server stress testing

Rehearse network and related APIs for games you host — never third-party multiplayer you do not control.

Abstract panels for regions, live metrics, L4/L7 methods, and reports on an authorized stresser platform — Features for authorized L4/L7 capacity tests

What to validate

Typical hypotheses: tickrate under connection pressure, NAT/firewall behavior, voice path stability, and lobby/matchmaking HTTP APIs. Split L4 (join/flood on IPs you own) from L7 (lobby JSON, auth, storefront) so a pretty status page does not hide a fragile matchmaker.

Instrument host CPU, packet drops, and player-facing latency while the Hub run is live. Abort when tick jitter or error rate crosses the budget you wrote before the window.

Full playbook: Game server stress testing guide. Layer primers: Layer 4 · Layer 7.

Recommended sequence

Stage or dedicated test shard with the same network path as production.
Verify the target IP/URL in Hub; confirm written approval for the window.
Short L4 smoke on the game port, then L7 smoke on lobby endpoints.
Raise concurrents only while tick and error budgets stay green.
File findings with concurrents, duration, and abort reason for the next patch.

Size capacity on pricing. Operator docs: developer docs.

Safety

Only servers and endpoints you own or have written permission to test. Hitting public multiplayer you do not operate is abuse — see Acceptable Use and authorized stresser vs booter.

All use cases · Start free · Status.

Game-stack pitfalls

Game capacity work fails when lobby HTTP APIs are tested but UDP game ports are not — or the reverse. Tick rate, player join storms, and chat/presence fan-out create different cliffs than a REST health check. Another pitfall is stressing a shared provider IP without isolating the shard you own, which can create collateral for neighbors and violate authorization boundaries.

Write the hypothesis per service: login API, matchmaking, or game transport. Pair L7 for lobbies with L4 for transport paths you operate. Guides: Layer 4, Layer 7, full playbook on the blog.

Run sequence for a title you host

Verify game and lobby targets; confirm the shard and window with ops.
Smoke lobby APIs at low concurrency; confirm auth and session creation metrics.
Exercise transport paths with authorized L4 methods appropriate to your stack.
Combine a join-storm style L7 scenario if matchmaking is the risk; keep abort tight.
Cool down and inspect sticky sessions, thread pools, and network buffers.

Size capacity on pricing. Start learning the Hub on a free trial. Policy: authorized load testing.

Metrics game teams should not skip

Join success rate and matchmaking queue delay under load.
Transport loss/jitter signals from your own telemetry (not only Hub Gbps).
Lobby API p95/p99 and error budgets.
Host CPU, NIC, and connection table headroom on the shard under test.

Hub tip: keep separate verified targets for lobby and game endpoints so reports stay unambiguous. Vocabulary: glossary. Automation: docs.

When not to run a game stress window

Do not target community servers you do not operate, anti-cheat vendor infrastructure, or platform APIs outside your written scope. Skip production shards during live tournaments unless the rehearsal is explicitly approved and abort criteria are aggressive. If you only need HTTP contract checks for a store API, prefer API load testing.

Resources hub · Glossary · Tools matrix · RPS calculator · Useful network tools · Blog · Pricing · Start free