A traffic crash happens when requests exhaust CPU, RAM, database connections or PHP workers faster than the server can answer. Read the error code first, check CPU and database connections in the panel, then add page cache and a CDN before you buy a bigger plan.
Why a traffic spike takes a site down
Each visit asks the server for PHP work, a database row and a few files. A campaign multiplies those asks within a minute. When CPU, RAM, database connections or PHP workers run out, the next visitor waits and then gets an error. The site did not lose its files; it ran out of room to answer.
- Uncached PHP running on every hit.
- A plugin that queries the database on the homepage.
- Images large enough that the network port fills before CPU does.
What to check first when traffic is crashing the site
Read the error the visitor sees before you touch a setting. A 503 or 508 means the worker or entry-process limit is full, a 500 means PHP hit a fatal error, and “Error establishing a database connection” means MySQL has no free connections.
- Load the site from another network to confirm the spike is real and not one bad connection.
- Note the exact error code and the page it appears on.
- Open the host panel and read CPU, RAM, entry processes and MySQL connections together.
- Turn on page cache for public pages and pause any plugin added in the last day.
- Check access logs for one IP or one crawler hitting hard; a scraper looks like traffic.
- Reload after each single change, and write down which change moved the number.
Only after those steps should you price a bigger machine. Changing plan mid-spike usually moves the site to a new server with the same slow query and the same missing cache. WebJi states a 99.9% uptime target; that is a target, and a full CPU still returns errors.
Caching so repeat visits skip PHP
A page cache stores the finished HTML, so the second visitor gets that copy instead of another PHP run. Carts, checkout and logged-in pages stay uncached, otherwise a person can see someone else’s basket. An object cache such as Redis takes repeated database reads out of the loop.
A CDN keeps images and cached HTML closer to the visitor, which is why the origin sees fewer repeats. Watch the cache hit ratio for a week: a low ratio means the cache is being bypassed, and no plan size fixes that.
Shrink images and fix slow queries before adding servers
Upload images at the size they are displayed, then compress and lazy-load them. Full-size photos are the usual reason a site that handled 200 visitors fails at 2,000, because the network port fills while CPU is still idle.
On the database side, read the slow query log for the week of the spike and index the columns you filter on. A page that fires one query per product row, the N+1 pattern, will use any extra CPU you buy, so fix the query loop before the plan.
What to do before a sale or a campaign
Warm the cache the day before, run a load test above the traffic you expect, and put the checkout through that test rather than only the homepage. If a normal Tuesday already sits near the CPU cap, move plan before the sale, not during it.
Write the campaign date, expected peak visitors per minute and the current cap in one line, and send it to whoever runs the ads. If the ads go out at 9 am, the plan change has to be finished the night before. The escalation path for the day itself is in what to do when the website is down.
When shared hosting is the wrong size
Shared hosting is the wrong size when a normal day already sits near the CPU or entry-process cap, or when a single campaign can double your peak. On 30 October 2026, WebJi shared plans are ₹300, ₹400 and ₹700 a month, a KVM VPS starts at ₹499 and Cloud Entry is ₹5,900, all before 18% GST.
A VPS gives a reserved slice with root access, and VPS hosting lists the sizes. Cloud hosting is the step after that, for a machine you can resize without a migration. Both are quoted with a date and GST on the invoice.
After the spike: what to change
Write down four numbers from the incident: peak concurrent visitors, error rate at the peak, the slowest query, and the cache hit ratio. Those four decide the next plan size, and they also show whether the fix worked when the next campaign arrives.
Then change one thing at a time: cache rule, index, image sizes, plan. A post-incident note of half a page is enough, as long as it names the cause rather than the symptom.
Frequently Asked Questions
What causes a website to crash from traffic?
Requests use up CPU, RAM, database connections or PHP workers faster than the server can answer. Uncached pages, database queries on every load and full-size images make that happen sooner.
What should I check first during a spike?
Read the error code: 503 or 508 means the worker or entry-process limit is full, 500 means a PHP fatal error, and a database connection error means MySQL connections are gone. Then read CPU, RAM and connections in the panel before changing anything.
Does a CDN stop a crash?
A CDN serves repeat reads of images and cached HTML, so the origin answers fewer times and survives a bigger spike. Checkout, login and cart pages still reach the origin, so they remain the limit.
When should I move off shared hosting?
Move when a normal day already sits near the CPU or entry-process cap, or when one campaign can double your peak. On 30 October 2026, WebJi shared plans are ₹300, ₹400 and ₹700 a month, a KVM VPS starts at ₹499 and Cloud Entry is ₹5,900, all before 18% GST.
Will a bigger plan fix a slow database?
Not by itself. A slow query or a missing index will use the extra CPU too, so read the slow query log and add the index first. A bigger plan buys headroom, it does not rewrite a bad query.
Is WebJi® an Indian company?
Yes. WebJi® is headquartered in Jaipur, Rajasthan and has operated since 2005. Billing, support and governance all run from India.
Do you provide GST invoices?
Every purchase and renewal gets a GST invoice with our GSTIN, and hosting prices are quoted exclusive of 18% GST. Claim input credit as applicable.