WordPress monitoring and APM that names the guilty plugin

3 layers

Response times zero-touch, full traces on consent, CPU flame graphs sampled from outside the process.

0 restarts

Everything is staged; the reload is your click, on your schedule. Always.

Per site

APM is opt-in per site with the price shown before you confirm — not per host, not per trace.

400+

Vhosts on a single box that the discovery, probing and billing were battle-tested on.

Attribution, not averages

Traces are WordPress-aware: time is attributed to plugins and themes by reading where each hook callback actually lives. The result reads like a verdict — "this plugin holds 21% of sampled page time on this site" — instead of a latency graph you still have to interpret. N+1 query patterns are detected automatically: the endpoint, the repeated query and the count, folded into one insight instead of four thousand events.

Three layers, each earning its keep

Layer one is zero-touch: request rates, error rates and response times per site, visible minutes after install, no code changes. Layer two adds method-level traces — the full waterfall from the request through hooks to every SQL query — staged by the agent and activated by your reload click. Layer three samples CPU flame graphs from outside the process, so even the 3 a.m. mystery load has a stack trace with file names. Old fleets are welcome: flame graphs work from PHP 7.2, traces from 8.1.

The parts of WordPress that break quietly

Every vhost is discovered from the real web-server config and watched as a site: certificate expiry (including origins hiding behind a CDN), DNS health, domain registration lapses and drop-catches, and a signal most stacks miss — a site whose PHP backend is gone, answering 502 to every dynamic request while its static cache still smiles at your uptime check. Bot storms hammering wp-login and probing for wp-config are counted and separated from real breakage by response status, so scanners do not page you at night.

What your visitors actually feel

Real User Monitoring captures Core Web Vitals — LCP, CLS, INP — plus JavaScript errors and rage clicks, injected automatically, with no theme edits. Visitor IP addresses are not stored: geography is resolved at ingest and the address is dropped, which keeps your privacy policy short. A slow field report connects to its backend trace, so "checkout feels sluggish in Italy" lands on the exact SQL query that caused it.

Dense hosting native

Aliases and www fold into one site, probes pace themselves on a rotating budget, and the console shows the exact folded list you are billed on.

Mixed PHP fleets

Multiple php-fpm versions on one box are handled per pool, per version. Each site gets the deepest layer its PHP carries, stated honestly.

Guardrails first

Instrumentation is built to fail open: if anything about a site's setup would break it, that site is skipped with a reason — never a white page.

Frequently asked

Will enabling APM restart my php-fpm?

Never by itself. The agent stages everything and the console shows you the exact reload command with its impact. You click, or you fold it into your next deploy. Wakora never restarts a client service on its own — that is a hard rule, not a default.

Does it work on shared hosting with hundreds of sites?

Yes — it was built on boxes carrying 400+ vhosts. Discovery parses the real web-server config, aliases and www variants fold into one site, probes run on a rotating budget so a dense box is never hammered, and APM is enabled per site, so you pay only for the sites you choose.

Which PHP versions are supported?

Response-time and error monitoring plus CPU flame graphs work from PHP 7.2. Full method-level traces need PHP 8.1 or newer. Mixed fleets are fine: each site gets the deepest layer its PHP version carries, stated honestly in the console.

Find the plugin before the client finds you.

Three hosts free, response times in minutes, traces when you say so.

Start free See pricing

When WordPress is slow,get the plugin's name.