ARC Raiders passed its pre-launch stress test — then overloaded anyway. Here's the soak lesson.

ARC Raiders launched on 30 October 2025 and reached over 300,000 concurrent players on Steam — a strong debut for a new extraction shooter from Embark Studios. Before launch, the team ran a “server slam” stress test. By all accounts, it passed.

Then, several days into launch, something changed. Reporting attributes the timing to sustained concurrency growth: as the player count kept climbing rather than tapering off, login queues grew, matchmaking slowed, and party and voice services broke. Players found themselves stuck in queues or unable to form groups.

Embark Studios did not publicly confirm the specific root cause of these issues. What reporting attributes to the situation is the pattern of a system that held at launch, then degraded as concurrency continued to grow — a different failure mode from the one a short pre-launch stress test is designed to catch.

What happened

ARC Raiders launched on 30 October 2025. The pre-launch stress test cleared the initial spike: the system absorbed the opening surge. For a period after launch, players were getting in. Then, around 2 November 2025, reports of login queues and matchmaking failures began circulating. Reporting at the time places concurrent player counts above 330,000 when these issues surfaced.

The pattern described in player reports is not a sudden crash — it is a gradual accumulation of problems. Login queues that grew longer over time. Matchmaking that became less reliable. Party formation and voice communication that degraded. These are the signatures of a system under sustained load rather than a system that hit an instantaneous wall.

The timeline

• 2025-10-30 — ARC Raiders launches. Pre-launch server slam test had passed. Initial player influx is absorbed.
• Days post-launch — Concurrent player count continues to grow rather than tapering to a steady state.
• ~2025-11-02 — Login queues, matchmaking failures, and party/voice issues emerge. Reporting ties the timing to sustained concurrency growth beyond the one-time peak the slam test modelled.
• Recovery — Embark works on server capacity; issues gradually ease as the studio responds. No detailed public postmortem has been released.

Why it happened

Reporting attributes the failure to a pattern where sustained concurrency beyond what a one-time stress test modelled exposed degradation the shorter test could not observe. Embark did not confirm a root cause publicly, so the following draws on the pattern reporting describes rather than a confirmed technical cause.

A pre-launch server slam test — or any short stress test — checks whether a system can survive a rapid load spike. It is designed to answer: “Can we absorb the opening surge?” It is not designed to answer: “What happens if we stay at or above that load for the next 48 hours?”

The answer to the second question is often different. Under extended high concurrency, degradation accumulates gradually:

• Connection pools — to databases, matchmaking services, or session stores — may hold steady at peak for 15 minutes, then begin saturating as long-lived connections accumulate without being recycled.
• Memory usage on stateful services (session servers, party services, voice routing) can drift upward slowly until a host approaches its limit and starts dropping requests.
• Queue depths grow when a downstream dependency — a session store, a matchmaking cluster — begins to fall behind throughput, adding latency to each player’s login flow.

A 10–15 minute slam test ends before any of these patterns manifest. A multi-hour soak test at the same concurrency level will surface all of them.

The failure pattern

This is soak-growth-collapse: a system holds at launch and through early peak, then degrades as concurrency continues to climb or as the duration at elevated load extends beyond what was tested. The word “collapse” is relative — it can mean a gradual error-rate creep that eventually breaks the player experience, not necessarily a binary outfall.

The pattern is particularly common in games with stateful session and matchmaking layers. Each active session holds resources on the server. A short test does not load-cycle sessions enough to observe pool saturation or memory drift. Only a test that sustains load for hours — through the lifecycle of multiple session opens, matches, and closes — will reveal whether the resource management is sound over time.

The soak / endurance test type is designed for exactly this scenario.

How it could have been prevented

The pre-launch slam test was the right instinct. The gap was in what it was asked to answer.

Pair the slam test with a soak test. A slam test should be complemented by a multi-hour soak at projected sustained peak concurrency — not just peak-of-the-spike. If the game is expected to hold 200,000 concurrent players for twelve hours on launch day, run the soak at 200,000 virtual users for at least six to eight hours in staging.

Add below-p50 resource monitoring. Error rates and p99 latency are lagging indicators. Memory-per-session on your session servers, connection-pool utilization on your matchmaking cluster, and queue depth on stateful services are leading indicators — they start moving before the player-visible errors appear. Instrumentation that surfaces these during the soak catches the accumulation pattern early.

Model the full session lifecycle, not just the login. A test that only sends login requests does not model the full server-side session lifecycle — the match formation, the in-session keep-alive, the disconnect and reconnect. Session servers need the full cycle to expose memory and connection patterns that accumulate.

Build in staged capacity bumps ahead of predicted growth. If player growth is faster than expected (a good problem to have), having pre-provisioned capacity tiers available — and a plan to activate them based on concurrency thresholds — reduces the lag between demand growth and capacity response.

How to test for this with MaxoPerf

The recipe here is a soak / endurance test, sustained for hours, not a spike that ends in minutes.

Profile shape

Use k6 or Taurus with an open-model workload:

• Ramp-up: 30 minutes from zero to your projected sustained peak concurrency. For ARC Raiders’ scale, that’s 150,000–200,000 virtual users; for your game, size it to your realistic peak.
• Hold: 4–8 hours at that concurrency. This is the load-bearing part of the test. Do not cut it short.
• Observation window: optionally ramp to 120–150% of projected peak in the final hour to model the “kept growing” scenario — the dynamic that reporting attributes to ARC Raiders’ post-launch degradation.

Target the stateful path

Point the test at your staging environment’s full session lifecycle: login → matchmaking request → party formation → session join → periodic keep-alive → disconnect. Each step in this sequence holds server-side resources. Testing only the login step will miss everything that accumulates in the downstream matchmaking and session layers.

What to watch in results

In MaxoPerf’s results view and metrics explorer:

• Error rate over time — is it flat for the first 30 minutes then slowly climbing? That’s the soak pattern.
• p95 and p99 latency trend — gradual latency growth under stable concurrency is a sign of resource accumulation.
• Throughput plateau — if achieved requests per second stops growing while you are still ramping virtual users, something upstream is saturating.

Set failure criteria that trigger if error rate crosses 1% or if p99 latency exceeds your threshold at any point during the hold phase. A clean spike test result with a failing soak result is the signal to investigate resource management before players find the problem.

Scheduling

Use MaxoPerf’s scheduled run capability to run the soak test automatically before every major patch that touches session, matchmaking, or party services. A change that does not affect peak performance can still introduce a resource leak that only appears after hours at load.

Key takeaways

• A pre-launch stress test checks whether a system survives a spike. It does not check whether it stays healthy under sustained load for hours. Both questions need answers before a large launch.
• Reporting attributes ARC Raiders’ post-launch issues to sustained concurrency growth beyond what a one-time test modelled. Embark did not confirm a root cause publicly — the lesson is the pattern, not a confirmed Embark engineering failure.
• Soak-growth-collapse is gradual: error rates creep, latencies drift, queues accumulate. These signals appear in multi-hour load tests long before they become player-visible problems.
• The session lifecycle — login, match, keep-alive, disconnect, reconnect — must be modelled in the test to expose connection-pool and memory-drift patterns. Login-only tests underestimate stateful resource pressure.
• Schedule soak tests as a regular gate for patches that touch session and matchmaking infrastructure, not only as a one-time pre-launch check.

If you are preparing for a multiplayer game launch or a major patch to stateful backend services, MaxoPerf’s soak / endurance test type provides the profile and observability to answer the question a slam test leaves unanswered.