WordPress is healthy most of the day. At roughly the same hour, pages begin responding slowly, the administrator stalls or WooCommerce checkout takes longer. Later, the site recovers without anyone changing it.
A scheduled pattern narrows the investigation. It often points to shared capacity: traffic, backups, WordPress cron, email queues, imports, security scans or another account on the server.
The mistake is to inspect the server only after it has recovered and conclude that nothing is wrong. The evidence must be aligned to the slow interval.
Build a timeline before changing capacity
For several occurrences, record:
- start and end time with timezone;
- affected URLs and actions;
- public, administrator or WooCommerce impact;
- traffic volume;
- PHP and MySQL resource indicators;
- jobs scheduled near that time;
- errors and timeouts;
- whether the site recovered by itself.
“Every morning” is not precise enough. A ten-minute delay beginning at 02:05 often has a different cause from a two-hour slowdown during business traffic.
Do not restart services as the first response unless availability requires it. A restart can erase the state that would identify the saturated resource.
Confirm whether the HTML response is delayed
During the affected interval, measure a representative URL:
curl -s -o /dev/null
-w '%{time_starttransfer} %{time_total} %{http_code}n'
https://example.com/Run occasional checks, not an aggressive loop. If you need continuous monitoring, use an agreed interval and store timestamps.
A high first-byte time across several simple pages suggests shared server work. If the HTML remains quick but one browser feature slows down, inspect that feature’s Ajax or external request.
Compare traffic before blaming a schedule
The same hour may simply be when customers arrive.
Review privacy-respecting analytics or server request counts by time. Compare:
- total requests;
- uncached requests;
- bots and legitimate visitors;
- WooCommerce transactions;
- search and filter requests;
- login attempts;
- large downloads.
A traffic peak becomes a capacity problem only when it saturates something. Identify whether PHP workers, CPU, memory, MySQL connections, disk I/O or an external quota reaches its limit.
Do not block traffic based solely on request volume. A promotional campaign can look unusual and still be valuable.
Inspect WordPress cron events
WP-Cron is triggered by site requests unless a real system scheduler is configured. Due events may begin when the first visitor arrives after their scheduled time.
List due events with WP-CLI:
wp cron event list
--fields=hook,next_run_gmt,next_run_relative,recurrenceLook for:
- events scheduled near the slowdown;
- duplicate hooks;
- tasks that remain overdue;
- unusually frequent recurrences;
- plugin jobs that process large datasets.
Do not delete unfamiliar events. Identify the plugin and the work performed. Removing the schedule may stop email, backups, stock updates or cleanup without repairing the underlying workload.
A real system cron can still overlap badly
Some installations disable request-driven WP-Cron and call it from cPanel, Plesk or the server scheduler. That is usually more predictable, but several jobs can still start together.
Review:
- system cron entries;
- cPanel Cron Jobs;
- Plesk Scheduled Tasks;
- backup schedules;
- malware scans;
- analytics imports;
- feed synchronisation;
- WooCommerce action queues.
Stagger independent heavy jobs where safe. Preserve dependencies: an export may need data produced by an earlier import.
Backups consume more than CPU
A backup can read thousands of files, compress data, query MySQL and upload an archive. The visible symptom may be high disk I/O rather than high CPU.
Check:
- backup start/end time;
- files and database included;
- compression level;
- local temporary space;
- remote upload duration;
- overlapping backups;
- whether old archives remain on the same disk.
Do not disable the only working backup to improve speed. Adjust timing, scope, incremental behaviour or storage after confirming the relationship.
Security scans can compete with PHP and MySQL
File and malware scans are valuable, but full scans at peak time can stress shared hosting or a small VPS.
Correlate scan logs with the slowdown. Look for:
- file enumeration;
- checksum comparison;
- database scanning;
- high I/O wait;
- repeated scans after failure.
Reschedule or tune the scan without reducing required coverage. A faster site with no reliable security monitoring is not an acceptable trade.
WooCommerce scheduled actions deserve their own view
WooCommerce and many extensions use Action Scheduler for email, webhooks, subscriptions, stock and background processing.
From WordPress admin, review scheduled actions and failed jobs. With WP-CLI where supported:
wp action-scheduler action list
--status=pending
--per-page=20Command availability depends on the installed WooCommerce/Action Scheduler tooling. Do not run or cancel actions in bulk without understanding their business effect.
A queue that grows at the same time every day may be the bottleneck or the result of an already saturated system.
Email bursts can create hidden application work
Newsletters, order notifications, form alerts and automated reports can trigger PHP and SMTP connections. If WordPress sends them synchronously, visitors may wait.
Check whether the scheduled interval coincides with:
- newsletter sends;
- WooCommerce follow-up email;
- membership notifications;
- form digests;
- failed SMTP retries.
Move high-volume campaigns to an appropriate mail system and use reliable queues where the application supports them. Preserve transactional email and consent requirements.
Imports and analytics reports may hit MySQL hard
Product feeds, order exports, search indexing and analytics dashboards can run complex queries. A task that was harmless with a small database may become expensive as the site grows.
Measure query time and rows examined during the interval. Check whether missing indexes, unbounded date ranges or repeated recalculation are involved.
Do not delete historical orders or analytics data merely to reduce table size. Repair the query, indexing or reporting method.
Shared hosting introduces neighbours you cannot observe directly
On shared hosting, another account can create temporary contention. cPanel or the host may show:
- CPU limit faults;
- physical memory faults;
- entry-process limits;
- I/O limits;
- concurrent-process limits.
Export the resource graph for the affected interval and ask the provider which limit was reached. A screenshot taken after recovery is weak evidence.
Moving hosting can be justified when measured limits repeatedly block legitimate work and the application is already reasonably configured. It should not be the first explanation for every scheduled slowdown.
PHP worker exhaustion has a distinctive pattern
When all workers are occupied, new requests queue. First-byte time rises while CPU may not look extreme if workers are waiting on MySQL or an external service.
Check:
- active/idle workers;
- queue length;
- slow request log;
- process duration;
- external HTTP calls;
- database locks and connections.
Increasing workers without enough memory or database capacity can make failure worse. Remove the slow work or size the whole stack coherently.
Capture state automatically, but keep monitoring proportionate
If the slowdown is brief, schedule lightweight collection around the expected time:
- timestamped response time;
- HTTP status;
- host resource metrics;
- PHP/MySQL status supplied by the host;
- job start/end logs.
Avoid logging personal data, URLs containing secrets or form contents. Monitoring should answer the performance question with minimal collection.
Verify by moving or repairing one cause
Once a job correlates with the interval, make one controlled change:
- move the backup;
- stagger cron;
- limit an import batch;
- repair a failed queue;
- tune a query;
- change scan timing;
- add justified capacity.
Observe the next scheduled interval. A correlation becomes stronger when the slowdown moves with the job or disappears after its repair.
Evidence for an intermittent performance assessment
Provide the exact timezone, two or three affected intervals, representative URLs, hosting resource graphs and known schedules. Include recent changes and whether checkout or forms are affected. Do not send passwords initially.
If WordPress is slow at predictable times, we can align application, job and hosting evidence to the same window. The result should identify the shared bottleneck and verify the repair during the interval when it previously failed.