Hollow Knight Silksong crashed Steam and three storefronts — the scheduled-release spike every publisher should test for

On 4 September 2025, Hollow Knight: Silksong launched after one of the longest waits in indie gaming history. Within minutes of the launch window opening, Steam, the PlayStation Store, the Nintendo eShop, and the Xbox Store all experienced disruptions. Purchase errors persisted for roughly three hours. PS5 and PS4 players were locked out for approximately two hours after the initial launch.

The game drew 535,213 players on its first day. That number is impressive. What made it dangerous to storefronts was not the total count — it was when those players arrived.

What happened

Team Cherry, the two-person studio behind Silksong, made a deliberate product decision: no pre-orders. The reasoning is understandable — they wanted players to judge the game on release, not commit to it years in advance. But that decision had a structural consequence: every buyer who had been waiting years for the game had to make their purchase at the same moment the store page went live.

The result was a concentrated transaction surge that crashed the purchase flows across multiple platforms simultaneously. Players saw payment errors, failed cart additions, and checkout timeouts. The outage was not a sign that the game was unpopular — quite the opposite. It was a case study in how a product decision about sales strategy directly shapes the load profile that storefronts must absorb.

The timeline

• 2025-09-04, launch window opens — Silksong becomes purchasable simultaneously across Steam, PS Store, eShop, and Xbox Store. Years of accumulated demand attempts to transact at once.
• Minutes after launch — Purchase flows on Steam begin returning errors. The PlayStation Store and Nintendo eShop follow.
• ~3 hours after launch — Purchase errors on Steam and most storefronts resolve. Players can buy the game.
• ~2 hours post-launch (PlayStation) — PS5 and PS4 players remain unable to purchase for approximately two hours after the initial disruption; this platform-specific lag suggests the PS Store checkout path had a different recovery curve than Steam.

Why it happened

The no-pre-orders decision transformed what would have been a spread purchase curve into a near-instantaneous spike. Under a pre-order model, demand distributes across weeks or months: many buyers purchase early, a cohort purchases on launch day, and a long tail follows over subsequent weeks. The purchase and authentication infrastructure sees a gradual ramp that autoscaling can match.

Without pre-orders, none of that demand was absorbed in advance. Every buyer who intended to purchase had to wait and then click at the same moment — or as close to it as they could manage. The checkout path — which involves authentication, entitlement creation, payment processing, and library update — saw a demand curve that was effectively a step function: near-zero to hundreds of thousands of concurrent transactions in seconds.

The purchase flow is harder to serve than a read-only storefront page. It touches payment processors, identity services, entitlement databases, and platform-specific DRM systems. Each of those has its own saturation point, and a simultaneous-arrival spike exposes all of them at once.

The failure pattern

This is a scheduled-release spike: a hard, predictable clock event that concentrates demand into a window so narrow that it functions like a step function from the backend’s perspective. The pattern applies to any product launch without pre-purchase options, any ticket sale without a queue, or any content drop announced for a specific time.

What makes it distinct from a flash sale or flash mob is that the arrival time is known in advance — by both the publisher and the engineering teams responsible for the storefronts. That means the failure is testable before it happens. The spike test pattern is designed exactly for this: model the concentrated arrival, measure where error rate departs from zero, and decide whether to pre-scale, add admission queues, or spread demand through other means.

How it could have been prevented

The engineering options exist on a spectrum from “change the product model” to “harden the infrastructure against the model you have chosen.”

Spread demand without requiring pre-orders. A countdown page that routes early visitors into a brief staggered queue — releasing purchase access in waves over 5–10 minutes rather than a single simultaneous moment — maintains the no-pre-orders spirit while avoiding a true step-function arrival.

Instrument the purchase path specifically. Storefront homepage reads and asset delivery handle concurrency differently than transactional checkout flows. Load tests that target only CDN-served read paths will underestimate the pressure on the checkout and authentication services.

Pre-scale before the launch window. If the launch time is known, provisioning decisions can be made in advance. Pre-scaling to 3–5× expected peak concurrent transactions eliminates the autoscaling-lag window that typically precedes a surge response.

Test the cross-platform scenario. When a game launches on multiple storefronts simultaneously, each storefront’s checkout flow fires at the same moment. Even if each platform’s infrastructure would handle the load alone, simultaneous demand across all of them stretches shared upstream dependencies — payment processors, identity providers, CDNs — that sit behind all of them.

How to test for this with MaxoPerf

The recipe for a scheduled-release spike targets your own purchase, authentication, and checkout path — the transactional endpoints, not the marketing page.

Define the workload model

Pick k6 or Taurus and model a spike profile:

• Pre-launch baseline: 500 virtual users for 2 minutes (normal browsing traffic).
• Spike ramp: scale to your expected day-one peak — for a game of Silksong’s stature, that’s tens of thousands of concurrent purchase attempts — over 30–60 seconds.
• Hold: sustain peak for 5 minutes to expose any stateful saturation (connection pools, entitlement queues) that appears only after the initial wave.
• Recovery: drop back to baseline; watch whether error rate recovers or whether the system stays degraded.

The spike ramp time of 30–60 seconds models the real behaviour: players have been watching a countdown, and many will click within the same minute.

Target the right endpoints

Point the test at your staging environment’s checkout flow: the sequence that covers session authentication, cart/add-to-library, payment intent creation, and confirmation. Measure requests per second at peak, p95 and p99 latency at each stage, and the error rate specifically at the checkout-completion step.

Run from multiple locations

Silksong’s audience was global. Use at least two managed geographic locations to model concurrent arrivals from different regions. If your checkout flow routes through a payment processor with regional endpoints, consider whether your managed locations reflect those routing paths.

Read the results

In MaxoPerf’s results view, watch:

• Error rate at the spike edge — any non-zero error rate in the first 60 seconds of the spike tells you the system cannot absorb the arrival rate.
• p95 checkout latency — if it climbs above your acceptable threshold during the hold period, you have a stateful saturation building behind the initial wave.
• Throughput plateau — if the measured requests per second stops climbing before you reach your target VU count, the system is already shedding load.

Use failure criteria to flag runs automatically: for example, fail the test if p99 checkout latency exceeds 5 seconds or if error rate exceeds 0.5% during the hold phase. That turns a manual review into a repeatable gate.

Key takeaways

• A no-pre-orders launch is a product decision with a direct load implication: all purchase demand concentrates into one minute. That minute needs to be tested.
• The checkout and payment path is the load-critical endpoint, not the storefront homepage. Test the transactional flow.
• Scheduled-release spikes are testable in advance because the arrival time is known. A spike test run against staging a week before launch is the simplest way to find the capacity ceiling.
• Pre-scaling to a concrete multiple of expected peak transaction volume — derived from a test, not a guess — is more reliable than relying on autoscaling to respond in real time during a 60-second surge.
• When a game ships simultaneously across multiple platforms, those platforms share upstream dependencies. Test the multi-platform scenario at the platform-combined concurrency level.

If you are preparing for a launch, ticket sale, or content drop with a hard go-live clock, MaxoPerf’s spike test gives you the profile and result signals to know whether your system is ready before your players find out otherwise.