Every year the same thing happens. A filing window or booking time approaches, millions of people open the same site within a few hours, and it crawls or errors out. People blame the department, the developers, or their own internet. The reality is more mundane and more useful to understand: it is an engineering and human-behavior problem, and knowing how it works helps you plan around it.
This guide is general background. We are not affiliated with any government department or portal, and we do not describe any specific system's internal design or capacity. Official portals and apps change often, so rely on their own notices for dates, rules and support.
The core problem: demand is not smooth
Most websites are built for a typical day, with some headroom. Deadline-driven services have a different shape of demand. Traffic is low for weeks, then rises sharply, then peaks in the last stretch before a cut-off. Capacity that is sensible for normal weeks looks tiny at the peak.
Three reasons the peak is so sharp:
- People wait. Deadlines create procrastination. Even people who could file early tend to act close to the limit.
- Everyone shares the same clock. A booking window that opens at a particular moment pulls many people to the same page together.
- Failure creates more traffic. When a page fails, people retry. A thousand users who each refresh five times become five thousand requests. This feedback loop makes the peak worse.
What is happening behind the error page
A request to a busy portal goes through a chain: your device, your ISP, the portal's front door (load balancer or CDN), application servers, a database, and often other systems such as banks, SMS providers or identity services. A bottleneck anywhere makes the whole chain slow.
Servers and queues
Servers can handle only so many requests at once. Extra requests wait in a queue. If the queue gets long, requests time out before they are served. That is why you may see a 504 Gateway Timeout or a generic "request timed out" message. If the system rejects work because it is overloaded, you may see 503 Service Unavailable. For more on these, read fix 503 Service Unavailable and fix 504 Gateway Timeout.
The database
Filing returns, updating records or booking seats involves writing data. Writes must be consistent: two people cannot both get the same seat or file conflicting versions. Systems protect consistency with locks and ordered processing, which limits how many writes can proceed in parallel. A database can become the slowest part even if web servers are fine.
Dependencies that sit outside the portal
Many flows rely on third parties:
- OTP and SMS delivery, where messages can arrive late during busy periods (OTP).
- Payment gateways and banks, which have their own limits and maintenance. See UPI payment failed or bank server down.
- Identity and verification services, which is why a login can fail even when the main page loads.
- Document issuers, in the case of document wallets.
A portal is only as fast as its slowest required dependency.
Protective limits
Operators may deliberately limit traffic to keep the system alive: rate limiting, captchas, waiting rooms, or temporary blocks on suspicious patterns. These can feel like randomness from the user side. Using several tabs, VPNs or scripts is more likely to trigger them.
Static versus dynamic pages
An information page can be cached and served cheaply. A logged-in form with live calculations cannot. So the "About" page may load quickly while the filing page is stuck. If a quick page loads and a form does not, the service is up but the dynamic part is overloaded.
Why scaling up is not simple
People often ask, "Why don't they just add more servers?" Sometimes they do, and capacity can often be added to stateless web layers. But some parts are harder:
- Databases and shared state do not scale by simply adding machines.
- Dependencies such as banks or SMS gateways are controlled by others.
- Cost and planning: capacity that sits idle for most of the year is expensive, while elastic cloud capacity needs software designed for it.
- Complex rules: tax, ID and booking systems contain years of rules that are risky to change quickly.
- Security and compliance: sensitive systems are hosted under specific policies that constrain how they can be scaled or moved.
None of this excuses poor experiences, but it explains why the same problems recur.
What you can do as a user
- Go early. If your task is open for weeks, do it in the first days, not the last. This is the single most effective habit.
- Prepare documents beforehand. Gather IDs, statements, bank details and numbers before logging in. Less time on the site means less chance of a session timeout.
- Choose quiet hours. Early morning and late evening often see lower load than office hours, although this varies. Treat it as a tendency, not a guarantee.
- Try the official app and the website. They may behave differently under load. Install only from links on the official site.
- Keep one session. Multiple tabs and rapid refreshes make things worse.
- Save references. Keep acknowledgment, ticket and payment reference numbers and screenshots. Check history before you resubmit to avoid duplicates.
- Check official channels. Maintenance notices and deadline changes are announced on the portal and official social accounts. Don't rely on forwarded messages.
- Stay safe. Never pay or share OTPs with anyone who offers to "fix" a portal. Type addresses yourself.
Tell whether it is the portal or your network
Before assuming the portal is overloaded, do a two-minute check:
- Open another busy official site and a big public site. If those are also slow, the issue may be your connection.
- Switch networks. If the portal works on mobile data but not on broadband, your ISP or DNS may be involved; see Jio and Airtel broadband: website not opening and change DNS on Indian ISPs and routers.
- Use Down From Where and the HTTP Status Checker to test from outside your network.
- Run the Website Speed Test to see whether the page responds slowly or not at all.
Our status pages for specific portals, such as IRCTC, income tax and GST, show whether those domains respond. They don't see inside logged-in features.
Lessons for businesses with their own deadline-driven sites
If you run a school admission form, an event ticketing page, a registration site, a results page or a sale, the same dynamics apply to you at smaller scale.
- Load test before the event. Know what your site does at several times normal traffic. See Black Friday website readiness checklist for a process that also fits Indian festival peaks.
- Cache what you can. Static assets and informational pages should come from a CDN.
- Make the heavy action cheap. Keep forms short, validate on the client, and avoid doing slow work (emails, PDFs) inside the request.
- Show clear states. "You are in the queue" or "try again in a few minutes" reduces refresh storms compared with a blank page.
- Open early, or stagger. Offer time slots, early windows or batches to flatten the peak.
- Monitor. Use an uptime monitor with short intervals during the event, and see how often you should monitor a website.
- Plan communication. Publish a status page and reuse status page communication templates.
Next steps
- Website down for everyone or just me?
- Check IRCTC status
- Income tax portal not working during ITR filing
- GST portal slow or down
- Black Friday website readiness checklist
FAQ
Is a slow government site the same as a down site?
No. Slow usually means requests are queued and eventually served. Down means requests fail. Both can appear as errors during peaks, so check from another network and retry calmly.
Will refreshing make the page load faster?
Generally not. Extra refreshes add load and can reset your session. Wait for the page to respond or time out, then retry once.
Does a different time of day really help?
Often, because load is lower, but no time can be guaranteed. If a task is open for weeks, doing it early is the more reliable approach.
Who should I contact if the portal fails?
Use the help or grievance section on the official portal and the contact details published there. Include screenshots and reference numbers, and do not trust numbers from random search results.
Get notified when this guide updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.