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 had disruptions. Purchase errors lasted for roughly three hours. PS5 and PS4 players were locked out for about two hours after the launch.

The game drew 535,213 players on its first day. The total was large, but the danger for the storefronts was the timing: when those players arrived.

What happened

Team Cherry, the two-person studio behind Silksong, decided on purpose not to offer pre-orders. They wanted players to judge the game on release instead of committing to it years in advance. That choice had a side effect. Every buyer who had waited years for the game had to buy it at the moment the store page went live.

The result was a concentrated transaction surge that crashed purchase flows on several platforms at the same time. Players saw payment errors, failed cart additions, and checkout timeouts. The outage showed demand, not a lack of it. It also shows how a sales-strategy decision sets the load profile a storefront has to absorb.

The timeline

• 2025-09-04, launch window opens: Silksong goes on sale at the same time on Steam, PS Store, eShop, and Xbox Store. Years of pent-up demand try to buy at once.
• Minutes after launch: Steam purchase flows start returning errors. The PlayStation Store and Nintendo eShop follow.
• ~3 hours after launch: purchase errors on Steam and most storefronts clear. Players can buy the game.
• ~2 hours post-launch (PlayStation): PS5 and PS4 players still cannot buy for about two hours after the first disruption. That platform-specific lag suggests the PS Store checkout path recovered on a different curve than Steam.

Why it happened

With no pre-orders, a purchase curve that would have been spread out became a near-instant spike. Under a pre-order model, demand spreads across weeks or months. Many buyers purchase early, a group buys on launch day, and a long tail follows over the next weeks. The purchase and authentication systems see a gradual ramp that autoscaling can keep up with.

Without pre-orders, none of that demand was absorbed early. Every buyer waited and then clicked at the same moment, or as close to it as they could. The checkout path covers authentication, entitlement creation, payment processing, and library update. It saw what amounts to a step function: from 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 calls payment processors, identity services, entitlement databases, and platform-specific DRM systems. Each has its own saturation point, and a spike where everyone arrives together hits all of them at once.

The failure pattern

This is a scheduled-release spike: a fixed clock event that packs demand into a window so narrow that the backend sees a step function. It applies to any product launch without pre-purchase, any ticket sale without a queue, and any content drop announced for a set time.

It differs from a flash sale or flash mob in one way: the publisher and the storefront engineering teams know the arrival time in advance. So you can test for the failure before it happens. The spike test pattern is built for this. Model the concentrated arrival, measure where the error rate leaves zero, and then decide whether to pre-scale, add admission queues, or spread demand some other way.

How it could have been prevented

The options run from “change the product model” to “harden the infrastructure for the model you chose.”

Spread demand without pre-orders. A countdown page can put early visitors into a short staggered queue and release purchase access in waves over 5–10 minutes instead of all at once. That keeps the no-pre-orders intent and avoids a true step-function arrival.

Instrument the purchase path itself. Storefront homepage reads and asset delivery handle concurrency differently from transactional checkout flows. A load test that only hits CDN-served read paths will understate the pressure on checkout and authentication services.

Pre-scale before the launch window. If you know the launch time, you can make provisioning decisions in advance. Pre-scaling to 3–5× expected peak concurrent transactions removes the autoscaling lag that usually comes before a surge response.

Test the cross-platform scenario. When a game launches on several storefronts at once, every storefront’s checkout fires at the same moment. Each platform might handle its own load. Together they still stretch the shared upstream dependencies behind all of them: payment processors, identity providers, CDNs.

How to test for this with MaxoPerf

A scheduled-release spike test targets your own purchase, authentication, and checkout path. Test 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 over 30–60 seconds. For a game the size of Silksong, that means tens of thousands of concurrent purchase attempts.
• Hold: stay at peak for 5 minutes to expose stateful saturation (connection pools, entitlement queues) that only shows up after the first wave.
• Recovery: drop back to baseline. Watch whether the error rate recovers or the system stays degraded.

A 30–60 second ramp matches real behaviour. Players have been watching a countdown, and many of them click within the same minute.

Target the right endpoints

Point the test at the checkout flow in your staging environment: 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 at the checkout-completion step.

Run from multiple locations

Silksong’s audience was global. Use at least two managed geographic locations to model arrivals from different regions at the same time. If your checkout routes through a payment processor with regional endpoints, check if your managed locations match 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 means the system cannot absorb that arrival rate.
• p95 checkout latency. If it climbs past your acceptable threshold during the hold, stateful saturation is building behind the first wave.
• Throughput plateau. If requests per second stop climbing before you reach your target VU count, the system is already shedding load.

Set failure criteria to flag runs automatically. For example, fail the test if p99 checkout latency goes over 5 seconds or the error rate goes over 0.5% during the hold phase. A manual review then becomes a repeatable gate.

Key takeaways

• A no-pre-orders launch is a product decision with a direct load cost: all purchase demand lands in one minute. Test that minute.
• The checkout and payment path carries the critical load, not the storefront homepage. Test the transactional flow.
• You can test scheduled-release spikes in advance because you know the arrival time. A spike test against staging a week before launch is the simplest way to find the capacity ceiling.
• Pre-scale to a concrete multiple of expected peak transaction volume, taken from a test rather than a guess. That is more reliable than counting on autoscaling to react during a 60-second surge.
• A game that ships on several platforms at once puts load on upstream dependencies the platforms share. Test at the combined concurrency of all platforms.

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