Skip to main content

APM

APM in the console is organized around sites (and Node services), not bare hosts: a card per site with requests, p95 and errors, and a detail page with traces underneath.

Enabling APM on a site​

APM is opt-in per site, and the site is the billing unit:

  1. Open APM. Sites already instrumented show as cards; everything else that could be instrumented waits in the candidates list below (sites of hosts where the APM runtime is active, and discovered Node services).
  2. Click Enable on a candidate. Within quota it is free of extra charge; past the quota the button states the price of the click before you confirm. History is present immediately, because spans were already flowing host-side.
  3. If the host itself is not instrumented yet, the host page's Action required card carries the staged activation: one paste-ready command (with its own backup, config test, and rollback) that you run in a maintenance moment. The agent never restarts your services itself; see Never restart your services.

Node services appear as candidates by their service name. A Node runtime below the supported floor shows an honest "blocked" pill instead of an Enable button that would do nothing.

The site page​

  • KPIs and charts: requests and p95 over 24 hours, with error-rate coloring; click a bucket to pin every block to that moment, click a day in the year strip for time travel further back.
  • Endpoints: the per-endpoint RED table.
  • N+1 insights: repeated-query patterns caught in traces, with the statement, the responsible plugin where detectable, and a view trace jump that highlights the matching rows in the waterfall.
  • Traces: slowest-first, expanding into a waterfall. Database spans are labeled with the SQL itself (trimmed, full text on hover), and repeated statements fold into one row with a multiplier. Time the request spent outside any child span (PHP computing, template rendering, anything the instrumentation does not wrap) is drawn as its own untraced time row when it is worth seeing, so a slow request with fast queries does not look like a mystery.
  • CPU flamegraph: sampled continuously, per site where PHP pools are per-site. "Who burns the CPU" attributes time to plugins, themes, core, or the app over the window you are looking at, with hot stacks alongside. The card says how old the newest sample is, and on a host that runs every site in one shared PHP pool it says so instead of showing a flame that would wrongly attribute the whole host's CPU to one site; the host's own flamegraph is one click away.
  • Deep trace: on WordPress sites, hook-level spans on a sampled fraction of requests. It is a per-host grant in the host's Manage card, off by default.
  • Manage: switching a site off stops the card and its billing; history stays. A removal row also stages the full un-instrumentation of the host when you want the runtime change gone.

What does not alert by default​

New APM signals never page anyone on day one: latency and error rules for sites exist in the catalog but ship disabled, armed only by your explicit choice in Alerting.