WordPress under high traffic: prevent and diagnose downtime

A campaign forecast expressed as monthly visits is insufficient for capacity planning. The origin server experiences requests arriving over seconds and minutes, each with a different processing cost. A crowd reading one public article may be served largely from cache, while a smaller group using product search, login and checkout can create much more dynamic work. Identify the expected peak arrival pattern, geographic distribution, landing pages and proportion of authenticated activity. Include scheduled imports and administrative work that might overlap the event. Establish practical service targets for the relevant journeys and agree what the team will do if those targets are missed. A hypothetical campaign target could specify a tested request mix, an acceptable slower-percentile response time and a limited error rate over a defined window. Those values must come from the client’s needs and tests, rather than a universal visitor limit or an unsupported uptime promise.

A 503 response says that a service is unavailable, but it does not identify whether PHP, a proxy, a hosting quota or an upstream dependency is responsible. A timeout similarly indicates that a deadline was exceeded somewhere in the request path. Correlate timestamps across CDN, web server, PHP-FPM, database and application logs. Check recent releases, worker queues, memory pressure, CPU, database waits, disk capacity and connection limits. External payment or stock services may explain long-running requests even when local CPU appears low. Compare edge errors with requests reaching the origin so the incident is not investigated at the wrong layer. Preserve representative evidence before restarting components when practical. A restart can temporarily restore service while erasing useful state; it should be an intentional recovery action with a known cost, not the only diagnostic technique available to the team.

Cache hit ratio is meaningful only with a clear denominator and context. Static assets, public HTML and personalized responses have different caching policies, so one combined percentage can hide a weak landing-page cache or a busy checkout. Inspect response headers and provider cache status, then group results by important routes and traffic types. Cloudflare distinguishes states such as HIT, MISS, BYPASS and DYNAMIC; understand what the installed configuration makes each state mean for your site. A miss may be expected on first access, while repeated bypasses can reflect cookies, headers or explicit rules. Track origin request rate alongside hit ratio because a high percentage on a much larger audience can still produce more origin work. Test invalidation after publishing and product changes. A cache that serves stale business information or another customer’s state is not a successful capacity improvement, regardless of its apparent hit rate.

Public pages are often good candidates for shared full page caching. Login, account details, cart state and checkout need explicit treatment because their responses depend on identity, session and transaction state. Review both paths and cookies, including AJAX and API endpoints that power these journeys. Do not assume a rule excluding one checkout URL covers every personalized response in the application. Use multiple test users and isolated sessions to confirm that no account data or cart content crosses between them. Verify that form tokens and session behavior remain correct after cached pages are served. Persistent object caching can still help appropriate data reuse during dynamic requests, but its keys and permissions must preserve the same boundaries. For abusive login traffic, apply targeted security controls with visibility into legitimate-user impact. A broad challenge or block can reduce resource use while preventing paying customers or editors from working.

Warm-cache tests can make capacity appear comfortable until a deployment, restart or broad purge sends requests back to PHP. Test that transition deliberately in a controlled environment. Identify popular pages whose simultaneous regeneration could concentrate database and worker load. Consider a measured warming process, selective invalidation and cache locking where the chosen stack supports it. Serving a bounded stale response during upstream trouble can be useful for suitable public content, but the freshness policy must match the business and must not extend to personalized or transactional responses indiscriminately. Cache layers need coordinated ownership so a plugin purge does not unexpectedly invalidate the entire delivery path. Monitor origin latency after publishing bursts as well as ordinary browsing. The goal is a system that can recover from its cache being empty without depending on every user arriving after someone else has already rebuilt the popular responses.

A useful load test represents the anticipated mix of reading, search, authentication and transaction steps. Increasing requests to a single cached URL mostly measures that cache path. Build tests against a representative staging environment or an explicitly approved production window with traffic ceilings and stop conditions. Use test accounts, sandbox payment systems and safe data, and coordinate third-party calls so the exercise does not send real emails or place real orders. Increase arrival rates progressively while recording throughput, response percentiles, errors, resource saturation and queue growth. Include sustained activity and recovery after the peak, not only a short burst. Note where the first constraint appears and repeat after one targeted change. If staging differs from production, document that limitation rather than reporting the result as a proven production capacity. The useful outcome is a measured operating range and a list of constraints, not a screenshot of an impressive request count.

Before an important event, assign an incident owner, escalation contacts and a short runbook linking symptoms to evidence and approved actions. The first priority is to restore useful service while protecting data. Depending on the diagnosed cause, suitable actions may include reverting a recent release, pausing a heavy import, limiting abusive traffic, serving allowed cached public pages or adding already tested capacity. Avoid changing several layers at once because the effect and rollback become difficult to understand. Preserve payment and order integrity when retrying operations or recovering a database. Define when a maintenance message is preferable to repeated failing transaction attempts. Backups support disaster recovery, but they do not solve a live worker queue automatically. After the incident, reconcile interrupted work and document timing, user impact, contributing conditions and the change that should prevent recurrence. A practical review improves the system instead of attributing every outage vaguely to high traffic.

8web can combine WordPress profiling, cache-policy review, load testing and managed infrastructure into a preparation plan for an anticipated traffic event. The deliverables should include the tested request mix, cache exclusions, resource observations, prioritized fixes, monitoring thresholds and recovery responsibilities. An engineering review may reveal that improving a search query is more valuable than buying additional workers, or that origin capacity is suitable but publishing purges are too broad. Hosting decisions then follow the workload rather than the marketing label of a server plan. During operation, monitor the customer journeys and leading indicators such as worker queue growth, database waits and falling hit ratios. Reassess after major plugin, catalogue or campaign changes. Resilience means reducing the likelihood and impact of failure and recovering with a prepared process; it is not a guarantee that a complex website and all its dependencies can never experience an interruption.