NEET UG 2025 results day crash — what 2 million simultaneous logins look like

When the National Testing Agency (NTA) declared NEET UG 2025 results on 14 June 2025, the country’s largest medical entrance exam website met the same fate it often does: it buckled under the weight of the moment it was built for.

More than 20 lakh (2 million+) candidates tried to access their scorecards at the same instant. The result was HTTP 503 and 504 errors, blank scorecard pages, failed logins, and captcha loops that resolved nothing. For students whose entire academic plans hinged on that score, even a one-hour delay was an ordeal.

This is the canonical form of a seasonal demand spike: a fully predictable, calendar-anchored surge that the system designer could calculate in advance — and yet it still caught the infrastructure unprepared.

What happened

On the morning of 14 June 2025, the NTA published NEET UG 2025 results. As soon as the announcement went out, candidates flooded neet.nta.nic.in to download scorecards. The site returned 503 Service Unavailable and 504 Gateway Timeout errors. Many users saw blank scorecard pages or partial results. Login failures and captcha loops added to the confusion. The issues persisted for multiple hours before the site stabilised.

The timeline

• Results declared: NTA announces NEET UG 2025 results; candidates begin rushing to the portal.
• 503/504 onset: Within minutes, the portal starts returning gateway errors as origin servers are overwhelmed; blank and partial scorecards appear.
• Login/captcha failures: Authentication and captcha systems slow to a crawl under the concurrent session load; candidates report failed logins across the country.
• Gradual recovery: Traffic pressure eases as candidates give up or succeed on retries; the site stabilises over several hours.

Why it happened

The root cause is a textbook capacity gap at a known peak. The NTA processes results for over 2 million registered candidates in a single batch declaration. Every one of those candidates, plus parents, coaching institutes, and the press, converge on the same URL within a narrow window of time.

Without pre-scaling origin servers, layered caching, queue management at the login/scorecard path, or a CDN edge that can absorb the static content — the request wave hits origin hardware directly. A system that handles modest administrative traffic year-round is suddenly asked to serve millions of concurrent, session-authenticated PDF downloads. The servers cannot keep up, and the queue of inbound connections simply grows until TCP backlogs fill and the gateway returns errors.

No official postmortem was published by the NTA. The pattern of simultaneous mass access to a result announcement is, however, consistent with the errors and outage reports filed by students and education trackers on the day.

The failure pattern

This is a seasonal demand spike: demand tied to a hard calendar event, arriving in a near-simultaneous burst, with no time-distribution possible because every user has the same incentive to act immediately.

The NEET pattern is not unique to exam boards. Any system with a high-stakes result, product release, or application window faces the same physics. The distinguishing feature is that the peak is predictable to the hour — which makes it both testable and inexcusable to miss. If you can write the date in a calendar, you can schedule a load test against it.

How it could have been prevented

Several layers of mitigation compound to raise the survivable concurrency ceiling:

Pre-scale before the window. Origin servers and database connection pools should be at peak capacity before the announcement goes out, not scaled reactively after errors appear. Autoscale warm-up lag is measured in minutes; a traffic wave arrives in seconds.

Layer a CDN for static and semi-static content. Scorecard PDFs and result lookup pages can be edge-cached or pre-generated per candidate. Caching the output of the scorecard generator for 30–60 seconds per candidate dramatically reduces origin hits.

Queue inbound requests at the auth boundary. A fair waiting queue (virtual waiting room) can absorb millions of inbound sessions without returning errors, turning a crash into a visible but manageable wait time.

Schedule a spike test against your own staging environment before the date. Run the test at the expected concurrent user count — not average daily traffic — and confirm p95 response times and error rates stay within acceptable bounds. Fix capacity gaps before the result declaration, not after.

Validate CDN offload and static generation end-to-end. A test that bypasses the CDN misses a critical layer. Run traffic through the same path candidates will use.

How to test for this with MaxoPerf

The right test type here is a spike test combined with a volume test when you need to confirm the system can sustain the throughput for the full drain of the queue.

Engine: k6 or Taurus with a closed-model concurrency profile.

Profile — spike:

• Baseline: 100 virtual users (normal admin traffic)
• Ramp to 50,000 virtual users over 60 seconds (simulating the announcement moment)
• Hold at 50,000 VUs for 10 minutes (candidates retrying and new arrivals)
• Ramp down over 5 minutes

Scale the VU count to your expected concurrent candidate count. For a 2-million-candidate exam, a realistic concurrent spike at announcement could be 200,000–500,000 simultaneous requests (each candidate may make 3–5 requests: login, captcha, scorecard fetch, PDF download). Start with 50k and step up until you find the failure knee.

Target: your staging environment behind the same CDN and auth layer as production — test the full path, not a bypass.

Execution locations: two or more MaxoPerf managed regions (to represent geographic distribution of candidates across India) plus a private/BYOC runner if your staging environment requires internal network access.

Signals to watch in results:

• Requests per second throughput at the spike peak — does it plateau or collapse?
• HTTP 503/504 error rate — should stay below 0.1% at expected peak
• p95 and p99 response time for the scorecard download path
• Login/auth error rate (a separate target path — test it independently)

Schedule the test using MaxoPerf’s scheduled run feature at least two to three weeks before the results date. That gives your team time to diagnose and fix capacity gaps, tune CDN rules, and re-run. A test run 24 hours before declaration is too late to fix anything meaningfully.

Read the results: open the MaxoPerf run results view and look at the throughput timeline alongside the error rate. If requests per second rises then drops as VUs hold steady, the system is shedding load without capacity. If error rate climbs monotonically, origin is saturating. If p95 latency spikes then recovers, a downstream queue or pool is temporarily exhausted.

Key takeaways

• A predictable calendar event is no excuse for an unplanned capacity ceiling — if you know the date, test against it in advance.
• The simultaneous-arrival problem means average traffic numbers are useless for sizing: test at the peak concurrent load, not the daily average.
• Layer caching, queuing, and pre-scaling so that each layer independently buys time — a CDN edge miss should not translate directly into an origin 503.
• Test the auth path separately; login is almost always the narrowest chokepoint in a concurrent-session spike.
• Schedule the test, not just run it once — recurring pre-event spike tests catch capacity regressions introduced by feature releases between seasons.

If your system has a results day, a release date, or any other fixed moment when your entire user base arrives at once, that date belongs on your load testing calendar. The spike test guide and the broader load failures series have more on building a practice that catches this before it becomes a headline.