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

The National Testing Agency (NTA) declared NEET UG 2025 results on 14 June 2025. The website of the country’s largest medical entrance exam then did what it often does: it failed at the one moment it exists for.

More than 20 lakh (2 million+) candidates tried to open their scorecards at the same instant. They got HTTP 503 and 504 errors, blank scorecard pages, failed logins, and captcha loops that went nowhere. For students whose academic plans depended on that score, even a one-hour delay hurt.

This is the textbook seasonal demand spike: a surge fixed to the calendar that anyone could calculate in advance. It still caught the infrastructure unprepared.

What happened

On the morning of 14 June 2025, the NTA published the 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 made things worse. The problems lasted several hours before the site stabilised.

The timeline

• Results declared: NTA announces NEET UG 2025 results, and candidates rush to the portal.
• 503/504 onset: within minutes the portal returns gateway errors as origin servers are overwhelmed, and blank and partial scorecards appear.
• Login/captcha failures: authentication and captcha systems slow to a crawl under the concurrent session load, and candidates across the country report failed logins.
• Gradual recovery: pressure eases as candidates give up or get through on retries. The site stabilises over several hours.

Why it happened

The root cause is a plain capacity gap at a known peak. The NTA publishes results for over 2 million registered candidates in a single declaration. Every one of those candidates, plus parents, coaching institutes, and the press, hits the same URL in a narrow window.

Without pre-scaled origin servers, layered caching, a queue in front of the login and scorecard path, or a CDN edge to absorb static content, the request wave lands straight on origin hardware. A system sized for modest administrative traffic all year suddenly has to serve millions of concurrent, session-authenticated PDF downloads. The servers fall behind, and the queue of incoming connections grows until the TCP backlogs fill and the gateway returns errors.

The NTA published no official postmortem. The pattern of mass simultaneous access to a result announcement does match the errors and outage reports filed by students and education trackers that day.

The failure pattern

This is a seasonal demand spike: demand tied to a fixed calendar event that arrives in a near-simultaneous burst. Nothing spreads it out, because every user has the same reason to act at once.

Exam boards are not the only ones exposed. Any system with a high-stakes result, a product release, or an application window has the same dynamics. What sets this pattern apart is that you can predict the peak to the hour. That makes it testable, and it leaves no excuse for missing it. 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 add up to a higher concurrency ceiling:

Pre-scale before the window. Bring origin servers and database connection pools to peak capacity before the announcement goes out. Do not wait to scale after errors appear. Autoscale warm-up takes minutes, and a traffic wave arrives in seconds.

Put a CDN in front of static and semi-static content. You can cache scorecard PDFs and result lookup pages at the edge, or pre-generate them per candidate. Caching the scorecard generator’s output for 30–60 seconds per candidate cuts origin hits sharply.

Queue incoming requests at the auth boundary. A fair waiting queue (a virtual waiting room) can absorb millions of incoming sessions without returning errors. Users see a wait they can live with instead of a crash.

Run a spike test against your own staging environment before the date. Test at the expected concurrent user count, not average daily traffic, and confirm that p95 response times and error rates stay within acceptable bounds. Close capacity gaps before the results come out.

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

How to test for this with MaxoPerf

Use a spike test, and add a volume test when you need to confirm the system sustains the throughput until the queue fully drains.

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 (the announcement moment)
• Hold at 50,000 VUs for 10 minutes (candidates retrying plus new arrivals)
• Ramp down over 5 minutes

Scale the VU count to your expected concurrent candidate count. For an exam with 2 million candidates, a realistic spike at announcement could reach 200,000–500,000 simultaneous requests, since each candidate may make 3–5 requests: login, captcha, scorecard fetch, and PDF download. Start at 50k and step up until you find where the system breaks.

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 model candidates spread across India) plus a private/BYOC runner if your staging environment needs internal network access.

Signals to watch in results:

• Requests per second at the spike peak. Watch whether it levels off or collapses.
• HTTP 503/504 error rate. Keep it below 0.1% at expected peak.
• p95 and p99 response time for the scorecard download path.
• Login/auth error rate. It is a separate target path, so test it on its own.

Schedule the test with MaxoPerf’s scheduled runs 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 run again. A test 24 hours before the declaration is too late to fix anything that matters.

Read the results: open the MaxoPerf run results view and compare the throughput timeline with the error rate. If requests per second rise and then fall while VUs hold steady, the system is shedding load because it lacks capacity. If the error rate climbs steadily, origin is saturating. If p95 latency spikes and then recovers, a downstream queue or pool ran out for a while.

Key takeaways

• A predictable calendar event is no excuse for an unplanned capacity ceiling. If you know the date, test against it in advance.
• When everyone arrives at once, average traffic numbers are useless for sizing. Test at peak concurrent load, not the daily average.
• Layer caching, queuing, and pre-scaling so that each layer buys time on its own. A CDN edge miss should not turn straight into an origin 503.
• Test the auth path separately. Login is almost always the narrowest point in a concurrent-session spike.
• Schedule the test instead of running it once. Recurring pre-event spike tests catch capacity regressions that feature releases introduce between seasons.

If your system has a results day, a release date, or any other fixed moment when your whole user base arrives at once, put that date on your load testing calendar. The spike test guide and the wider load failures series cover how to build a practice that catches this before it becomes a headline.