SSA "My Social Security" portal crashes — the cost of skipping a load test before launch

In early 2025, the Social Security Administration’s “My Social Security” portal crashed roughly four to five times in the space of weeks. The portal serves around 70 million beneficiaries. Each crash locked users out of benefit statements, payment histories, and direct deposit settings — services many Americans depend on for basic financial planning.

This is the case study that the load testing world returns to when explaining why you test before you ship — not after. And it has a named cause, cited in reporting: technology staff did not test the software against a high volume of users to see if the servers could handle the rush.

What happened

In March 2025, the SSA portal began crashing repeatedly. Newsweek reported that the Social Security Administration confirmed it was responding to the crashes and working to stabilise the site. Gizmodo’s reporting linked the crashes to a software update that had recently been deployed. The site went down multiple times over a period of weeks, leaving tens of millions of users unable to access their accounts.

The pattern was not random. Each crash corresponded to a surge of users trying to log in — a predictable thundering herd against a newly modified authentication path.

The timeline

• Software update deployed: A new anti-fraud check is introduced earlier in the authentication flow, meaning a larger share of login attempts now reach the fraud-check step.
• Crashes begin (March 2025): The portal starts experiencing repeated outages; the SSA confirms it is responding to crashes.
• Mass login surge: Anxious beneficiaries — many checking on potential benefit changes — flood the login page simultaneously, amplifying load on the new auth path.
• Four to five crashes over weeks: Reporting documents multiple failures across the period.
• Attribution: The Washington Post, cited via Fortune, reported that technology staff had not tested the software against a high volume of users before launch.

Why it happened

The proximate cause, as attributed in reporting, was that the software was not tested against high user volumes before it went live.

More specifically: the update inserted a new anti-fraud check into the login path. Previously, this check ran later in the flow — or not at all for many sessions. Moving it earlier meant that every login attempt now triggered it. The fraud-check step was presumably sized for its original, narrower role in the flow. Suddenly it had to process the full concurrent login volume of a site with tens of millions of active users.

When anxious beneficiaries — many checking on news about potential changes to their benefits — piled onto the site simultaneously, the result was a textbook thundering herd against an undersized authentication service. The system collapsed under the combined weight of high legitimate demand and an auth path that had never been validated at that concurrency level.

The Gizmodo report connected the crashes to the software update directly. The Fortune piece provided the clearest public statement on the testing gap.

The failure pattern

This is a thundering herd at a new authentication path — a specific variant of the broader thundering-herd class that is especially dangerous because it happens invisibly during development. The auth path existed before the update, but the update changed which users hit it and when. Without a load test of the modified path at realistic concurrency, that change was invisible to the team until production collapsed under it.

The generalisation for any team: any change that moves load to an earlier point in a user flow, or that activates a previously lightweight service under full concurrency, must be load tested as if it is new infrastructure. Because from a load perspective, it is.

How it could have been prevented

Load test the modified path before launch, not after. The missing step was explicit: the software was not tested against high user volumes. Running a load test on the anti-fraud-check path at the expected concurrent login volume before deployment would have revealed the capacity gap.

Test the specific path that changed — not just the overall site. The auth/fraud-check step is a distinct backend flow. It deserves its own load profile, separate from a general site load test. Target the login endpoint directly and ramp virtual users to your production concurrent session count.

Define a failure criterion before the test runs. Decide in advance what acceptable p95 response time and error rate look like at peak concurrency. If the test exceeds those thresholds, the release does not go out until the fix is validated.

Pre-scale the new dependency. If the fraud-check service was sized for its previous role, it needs to be re-sized for full login-path concurrency before it is promoted to that role. Load testing identifies the required capacity; provisioning it is a pre-launch action.

Run a spike to simulate the mass-login surge. Beneficiaries arrived in a concentrated burst. A spike test models that scenario better than a gradual ramp — you need to know what happens when login attempts arrive simultaneously, not sequentially.

How to test for this with MaxoPerf

The test type that matches this failure is a load test on the auth path specifically, combined with a spike test to model the mass simultaneous login scenario.

Engine: k6 or JMeter, targeting the login and session-creation endpoints.

Profile — load test (baseline validation):

• Ramp from 0 to expected peak concurrent sessions over 3 minutes
• Hold at peak for 15 minutes
• Watch for error rate onset and p95 response time degradation

Profile — spike (thundering herd simulation):

• Baseline: 500 virtual users
• Near-instant ramp to 10,000–50,000 VUs over 30 seconds (model the simultaneous login wave)
• Hold at peak for 5 minutes
• Ramp down over 2 minutes

Set the VU count based on your concurrent session data from the busiest period you have seen in production. For a site with tens of millions of registered users, the simultaneous login peak during a high-anxiety news event could be orders of magnitude above normal.

Target: staging environment with the modified auth path deployed — including the new anti-fraud check. Do not test the old path and call it done. Test the changed path at production-like concurrency.

Execution locations: MaxoPerf managed regions. Run from multiple locations to distribute login source IPs and avoid triggering rate limits on the test itself.

Signals to watch in results:

• Login endpoint error rate — target zero at expected peak
• p95 and p99 response time for the auth round-trip
• Virtual user throughput at the spike peak — does it sustain or does the system start rejecting connections?
• Downstream dependency response time (if your fraud-check calls an external or internal service, add that to your monitoring)

Gate the release. If the load test shows degradation above your threshold at expected peak, treat that as a release blocker. A clean test result at realistic concurrency is the criterion for going live — not developer confidence or a single manual test.

Key takeaways

• A software update that reshapes which users hit a backend service is a load event, not just a code change — test it accordingly.
• The SSA case is the clearest public example of what happens when load testing is skipped: the system works in development and collapses in production on the first day of real concurrent load.
• Testing the changed path specifically is essential — a general site load test would not have exercised the anti-fraud-check path at full concurrency before the update.
• Failure criteria must be defined before testing, not after, or the results have no actionable meaning.
• The fix for a missing load test is straightforward: run the test against your own staging environment before the next change ships.

The load test guide, the spike test guide, and the load failures series go deeper on building a pre-launch testing practice that catches this class of failure before it reaches production.