Skip to content

wp_sustained_slowness

Severity: Warning Signal: wp_slow_requests_total — slow frontend page loads sustained across multiple sample windows

What this signal means

Frontend page loads on this site have been slow across at least three consecutive sample windows (~90 seconds total). This is distinct from wp_slow_page_load, which fires when a specific URL is slow once — this rule fires when the site as a whole is slow, which has different causes.

What surprise this prevents

The site being slow for a stretch of time without a single page being catastrophically broken. From the customer's perspective the site feels degraded — clicks take longer, navigation hangs, the admin is sluggish — but nothing is "down." Per-page alerts don't capture this shape because no single page is the problem.

Why it matters

When PHP execution is healthy (no errors, no warnings, normal memory) but pages are consistently slow, the cause is usually outside PHP — the host running the site is contending for CPU, memory, or disk I/O. This is the most common cause of customer complaints about "the website being slow" and the easiest to misdiagnose as a WordPress problem.

Investigate

View entity alerts in Logystera →

Check the entity dashboard for the recent window:

  • wp_request_duration_ms p95 — how much higher than normal is it?
  • wp_request_errors_total — is the error rate still zero? (If yes, this is host-level, not application-level.)
  • wp_php_warnings_total — any spike? (If yes, application logic may also be involved.)
  • wp_request_peak_memory_mb — is PHP memory pressure rising? (If no, PHP itself is healthy.)

The diagnostic pattern that points to host pressure:

Signal Normal during this alert
Error rate Flat at zero
PHP warnings Flat
PHP peak memory Flat
Request duration Elevated

When that pattern holds, the cause is almost certainly outside your WordPress installation.

  1. Check the host running this site.
  2. Shared hosting: contact your host. Ask whether load on the shared machine is elevated.
  3. VPS / dedicated: SSH in and check uptime (load average), free -m (memory), top / htop (top processes).

  4. Containers: check whether the WordPress container is being CPU-throttled or memory-pressured by sibling containers on the same host.

  5. Look for memory pressure on the host. Run dmesg | grep -i 'killed process' — if the kernel has been killing processes for memory, the host is OOM-thrashing. WordPress doesn't need to be the killed process to be affected; the whole machine slows down during an OOM event.

  6. Look for unrelated workloads consuming resources. A CI runner, a backup job, an antivirus scan, or a search-index rebuild on the same host will slow WordPress without leaving any trace in WordPress itself.

  7. If the host is healthy:

  8. Check whether a slow database query is involved — install Query Monitor and inspect a slow page.
  9. Check whether a blocking external HTTP call is involved (payment gateway, social API, SEO tool).

  10. Check whether opcache or object cache was just cleared, causing a transient cold-start window.

  11. If this keeps happening on the same shared host, consider moving to a host with isolated resources. Sustained slowness on shared hosting almost always means a neighbour is consuming more than their share.

When to safely ignore

This rule is intentionally sensitive — it will fire during planned heavy operations like a large import, a bulk media regeneration, or a full backup. If you know what's running and the slowness is expected, acknowledge the alert. The record_only delivery mode (tunable) can be used to silently record sustained-slowness events for review without inbox noise during periods of known background work.

Tuning

The rule's defaults work for most sites: - Fires after 3 slow sample windows within 90 seconds - Suppresses repeat alerts for the same entity for 15 minutes

Increase threshold_count if the rule is too sensitive on your traffic pattern. Decrease it if you want earlier detection. The minimum useful interval is roughly the scrape cadence (15s) × 2 = 30s.

Signal reference

wp_sustained_slowness is derived from wp_slow_requests_total, a counter incremented by the WordPress plugin whenever a frontend request exceeds the slow threshold (default 5000ms). The rule examines the rate at which this counter grows across consecutive sample windows.

wp_slow_requests_total{entity_id="...",route_group="frontend",method="GET",is_bot="false"}