WordPress Performance Monitoring: New Relic, Datadog and Query Monitor

WordPress performance monitoring tools give you real data about what is actually slowing your site down. Without visibility into transaction traces, slow queries, and real user load times, you are guessing. New Relic, Datadog, and Query Monitor each approach that problem from a different angle, and together they cover every layer of a production WordPress stack. This guide walks through setting up each tool, reading the data they surface, and acting on it before your users notice a problem.

Why WordPress Performance Monitoring Is Not Optional

Most WordPress site owners rely on occasional Lighthouse scores or GTmetrix snapshots to gauge performance. Those tools capture a single synthetic page load from a fixed network, they tell you nothing about what your real visitors experience at peak traffic, what your database is doing during a WooCommerce checkout, or whether your object cache is functioning at 2 am when your cron queue runs.

Production-grade wordpress performance monitoring tools close that gap. They run continuously, instrument every request, and alert you when something drifts outside normal bounds. The three tools in this guide cover complementary layers:

• New Relic, full-stack Application Performance Monitoring (APM) with PHP agent instrumentation, transaction tracing, and infrastructure metrics
• Datadog, unified observability platform with distributed tracing, log correlation, and highly configurable alerting thresholds
• Query Monitor, free WordPress plugin giving developers real-time query profiling, hook timing, and HTTP request inspection directly inside the admin bar

New Relic for WordPress: APM Setup and Transaction Tracing

New Relic’s PHP agent sits between your web server and PHP-FPM, capturing every request automatically. Setup takes under ten minutes on most managed hosts, and the data you get back is immediately actionable.

Installing the New Relic PHP Agent

New Relic provides an automated installer that detects your PHP version and web server. On a Debian/Ubuntu server you download and run the installer script after retrieving your license key from the New Relic console under Account Settings → API Keys.

After installation, open /etc/php/8.x/fpm/conf.d/newrelic.ini and set your application name and license key. Restart PHP-FPM, then load any WordPress page, within two minutes you will see your first transactions appear in the New Relic APM dashboard under the application name you chose.

On managed hosts like WP Engine or Kinsta, New Relic integration is available directly in the hosting dashboard without server-level access. Enable it there and skip the manual agent install entirely.

Reading WordPress Transaction Traces

Once data flows in, navigate to APM → Transactions. New Relic groups PHP requests by URL pattern. For WordPress this typically surfaces / (homepage), /wp-admin/admin-ajax.php, and individual post slugs as the highest-traffic transaction types.

Click any transaction to open the trace waterfall. Each segment shows you:

• Time in PHP, your theme, plugins, and WordPress core executing
• Time in MySQL, database queries, broken down per query
• External calls, any HTTP requests made during the page build (payment gateways, REST APIs, font providers)
• Memcached/Redis segments, object cache hits and misses

A healthy WordPress page should show the majority of time in PHP with a short MySQL segment and zero or near-zero external calls on the critical path. If MySQL occupies 60%+ of a transaction, you have a query problem. If external calls are blocking the response, they need to be moved off the critical path or cached.

Identifying Slow Queries with New Relic

Navigate to APM → Databases. New Relic shows every distinct SQL query along with its average execution time, call count, and total time contribution. Sort by “Throughput” to find the most frequently called queries, then by “Average response time” to find outliers.

Common WordPress slow-query patterns that appear here:

• Post meta lookups without an index on meta_key, typically from plugins querying wp_postmeta with many conditions
• User capability checks on large user tables, the wp_capabilities user meta key is read on almost every request
• WooCommerce order queries with no date range filters, full table scans on wp_posts for post_type = shop_order
• Taxonomy term relationship joins, especially on archive pages with complex WP_Query arguments

When you identify a problematic query, click it to see which PHP stack frames triggered it. That trace points directly to the plugin or theme code responsible, so you know exactly where to optimize rather than guessing through twenty plugins.

New Relic Real User Monitoring (Browser Agent)

New Relic’s Browser agent instruments actual visitor sessions. Enable it from the APM application page under Settings → Browser Monitoring. Choose the “Auto-inject” option, New Relic injects a JavaScript snippet into every HTML response automatically via the PHP agent, so you do not need to touch your WordPress theme.

The Browser dashboard surfaces Core Web Vitals (LCP, INP, CLS), JavaScript errors, AJAX call timings, and geographic breakdowns of load times. Correlating your RUM data with APM traces lets you answer a question that synthetic tools cannot: “Are the users who load slowly the ones generating high server-side transaction times, or is their slowness purely client-side?”

Setting New Relic Alerting Thresholds

Without alerts, a monitoring dashboard is just a screen you check occasionally. Go to Alerts → Alert Policies and create a policy for your WordPress application. Recommended thresholds as starting points:

Tune these thresholds after a week of baseline data. Every site is different, a membership site with authenticated queries will have naturally higher baseline response times than a static blog.

Datadog for WordPress: Distributed Tracing and Unified Observability

Datadog differentiates itself from New Relic in two ways for WordPress stacks: its log management is deeper, and its alerting and dashboard system is far more flexible. It also integrates naturally with infrastructure metrics so you can see PHP-FPM worker saturation, MySQL replica lag, and Redis evictions all in one view alongside your application traces.

Installing the Datadog Agent and PHP Tracer

Datadog uses a two-component model. The Datadog Agent runs as a system daemon collecting host metrics, logs, and forwarding traces. The PHP tracer is a separate package that instruments your PHP processes.

Install the Datadog Agent on your server using the one-step installer from your Datadog dashboard under Integrations → Agent. Select your OS and run the provided command with your API key. The agent starts immediately and begins sending host metrics (CPU, memory, disk I/O, network).

Next, install the PHP tracer package. Datadog publishes .deb and .rpm packages via GitHub releases and their own package repository. After installation, add the required INI directives to your PHP configuration, the tracer reads your DD_SERVICE, DD_ENV, and DD_VERSION environment variables to tag all traces correctly.

Set meaningful values for these variables. Using DD_SERVICE=attowp-wordpress, DD_ENV=production, and DD_VERSION tied to your WordPress version or deploy hash makes filtering traces by environment trivial when you are also running staging or development alongside production.

WordPress-Specific Datadog Configuration

Out of the box, Datadog’s PHP tracer instruments PDO and MySQLi automatically, so all WordPress wpdb queries are captured without any plugin or code changes. Enable the Nginx or Apache integration in the agent configuration to correlate access logs with your traces.

For log correlation, the ability to click a slow trace and jump directly to the PHP error log lines generated during that exact request, add these settings to your PHP-FPM pool configuration:

Set catch_workers_output = yes and point your access.log to a file the Datadog Agent log collection reads. In the agent’s conf.d/php.d/conf.yaml, configure log collection with the correct path and set service and source to match your APM service name. After a restart, traces in Datadog APM show a “Logs” tab that displays the correlated log lines for that specific request.

Transaction Tracing and Slow Query Detection

Datadog APM’s Traces Explorer lets you query traces using a search language that filters by service, resource name, duration, HTTP status, and any custom span tags. To find all WordPress requests slower than one second: set the duration filter to > 1s and service to your WordPress service name. Sort by duration descending.

Click any trace to open the flame graph. Datadog’s flame graph is visually cleaner than New Relic’s waterfall view and handles highly nested WordPress call stacks well, each plugin’s action/filter hooks show as distinct spans when they exceed the minimum duration threshold (configurable, defaults to 1ms).

Database spans appear in the flame graph under the mysql service. Click any database span to see the full SQL query, the table it hit, and the row count returned. High row counts on simple-looking queries often indicate missing indexes that EXPLAIN would confirm.

Building WordPress Performance Dashboards in Datadog

Datadog’s dashboard builder is highly composable. A useful WordPress performance dashboard combines widgets from three data sources:

1. APM service metrics, trace.web.request.duration.by.resource (percentile breakdown per URL), trace.web.request.errors, trace.db.mysql.query.duration
2. Infrastructure metrics, system.load.5, php_fpm.listen_queue.size, mysql.net.connections, redis.mem.used
3. RUM metrics (if using Datadog RUM), rum.view.loading_time (p75 and p95), Core Web Vitals, error rates by browser

Clone Datadog’s official “PHP APM” dashboard from the integration gallery and add WordPress-specific panels on top rather than building from scratch. This saves an hour and gives you a solid baseline layout.

Datadog Alerting: Composite Monitors and Anomaly Detection

Datadog’s alerting system is one of its strongest differentiators. Beyond simple threshold alerts, it supports:

• Anomaly monitors, alert when a metric deviates from its historical pattern, even if it stays below a fixed threshold. Useful for catching gradual degradation that would never trigger a static alert
• Composite monitors, fire only when multiple conditions are true simultaneously. Example: alert when response time is elevated AND error rate is elevated AND PHP-FPM queue is nonzero. This eliminates false positives from temporary traffic spikes
• Forecast monitors, project a metric forward using historical seasonality and alert if it is predicted to cross a threshold. Useful for disk space on busy wp-content upload directories

For a WordPress production site, start with three monitors: a composite monitor combining high p95 response time with elevated error rate, an anomaly monitor on MySQL query duration, and a threshold monitor on PHP-FPM queue size. Route critical alerts to PagerDuty or Slack; route warnings to email only.

Query Monitor: Real-Time WordPress Database and Hook Profiling

Query Monitor is a free WordPress plugin available on the plugin repository. Where New Relic and Datadog are infrastructure-level tools requiring server access, Query Monitor runs entirely inside WordPress and requires only plugin activation. It is the fastest way for a developer to identify slow queries and hook timing issues on any WordPress installation, including local development, staging, and shared hosting where you cannot install agents.

Installing and Configuring Query Monitor

Install Query Monitor from Plugins → Add New or via WP-CLI with wp plugin install query-monitor --activate. Once active, an admin bar item appears showing the total query count and total query time for every page load.

Query Monitor is only visible to users with the manage_options capability (administrators) by default. To enable it for a specific non-admin user, add a QM_DB_QUERIES authentication cookie, the plugin documentation covers setting up the cookie-based authentication for non-admin profiling sessions.

For production use, install Query Monitor’s db.php drop-in. Without it, Query Monitor instruments queries through a custom database class, but the drop-in provides deeper early-bootstrap query capture. Drop the file into wp-content/, the plugin’s admin notice guides you through this one-time step.

Reading Query Monitor’s Database Panel

Click the admin bar item and select Queries. The panel lists every database query executed during the current page load:

• Query, the full SQL statement
• Caller, the PHP function or method that triggered the query, with a link to the source file and line number
• Component, whether the query came from WordPress core, a specific plugin, or your theme
• Time, execution time in milliseconds
• Rows, the row count returned

Sort by time descending to find the slowest queries. A production WordPress page should have its slowest individual query under 50ms, anything above that is worth investigating. Filter by component to see which plugin is responsible for the bulk of your query load.

The Duplicate queries filter is particularly revealing. Many WordPress plugins query the same data multiple times per request without using transients or the object cache. Seeing the same SELECT on wp_options executed 40 times in a single page load is a clear signal that caching is missing or broken.

Hook and Action Timing with Query Monitor

Beyond database queries, Query Monitor’s Hooks & Actions panel shows every WordPress action and filter that fired during the request, along with which callbacks are attached to each hook. This is invaluable for diagnosing slow custom code hidden inside hooks like wp_head, the_content, or WooCommerce’s woocommerce_checkout_order_processed.

The HTTP API Calls panel surfaces any outbound HTTP requests made by WordPress core or plugins during the page build, a common source of slow page loads that no amount of database optimization will fix. Each entry shows the URL called, the HTTP method, the response code, and the time taken. Calls to external APIs on the critical render path need to either be cached via transients or moved to an asynchronous queue.

Using Query Monitor on Production Sites

Query Monitor has negligible overhead when logged out. When logged in as an administrator, the overhead is present but acceptable for diagnostic sessions. The recommended practice for production is to keep Query Monitor installed but inactive, then activate it briefly for a profiling session when investigating a reported performance issue. Deactivate it again when done.

An alternative is to use Query Monitor’s environment variable integration: set QM_DISABLED=true in your wp-config.php by default, then temporarily comment it out for profiling. This prevents any overhead even when the plugin is active.

Comparing New Relic vs Datadog vs Query Monitor

Each tool covers different layers of the monitoring problem. Understanding where they overlap and where they diverge saves you from over-investing in tools you do not need.

The practical recommendation: run Query Monitor during development and initial debugging to identify issues at the WordPress layer, then use New Relic or Datadog in production for continuous monitoring, alerting, and historical trend analysis. You do not need both New Relic and Datadog unless you are already invested in one platform’s broader ecosystem.

APM Setup Best Practices for WordPress

Getting the most out of any APM tool on WordPress requires a few WordPress-specific configurations that the generic setup guides do not cover.

Name WordPress Transactions Meaningfully

By default, both New Relic and Datadog group all WordPress requests under the front controller path /index.php or the request URI. This makes your APM dashboard useless, everything shows as a single transaction type. You need to set transaction names to reflect what the request actually is.

For New Relic, use the newrelic_name_transaction() PHP function hooked early in WordPress. A small must-use plugin that calls this function after parse_request fires can set names like singular/post, archive/category, admin/ajax/action-name, and woocommerce/checkout. This turns a flat list of anonymous requests into a meaningful breakdown of your site’s request types.

Datadog handles this through the DD_TRACE_URL_AS_RESOURCE_NAMES_ENABLED setting combined with custom resource naming via the tracer API. The approach is similar: hook into WordPress early, detect the request context, and set the resource name on the active span.

Exclude Admin Ajax from Standard Averages

WordPress’s admin-ajax.php endpoint handles dozens of different background actions, heartbeat, autosave, WooCommerce cart updates, plugin-specific callbacks. Grouping all of these into a single average response time metric creates noise. Segment them by action parameter or exclude admin-ajax.php from your primary performance indicators and track it separately.

In New Relic, use Key Transactions to highlight the admin-ajax actions that are business-critical (checkout, payment processing) and give them separate Apdex thresholds. In Datadog, use resource-level filtering in your monitors to separate noisy background actions from user-facing request performance.

Monitor Cron and WP-CLI Separately

WordPress cron runs via HTTP requests to wp-cron.php or via real system cron calling WP-CLI. Both APM tools capture these as PHP transactions. Tag them separately from web traffic, you want to know if a scheduled email sending job is taking twelve minutes without that skewing your web response time averages.

Set newrelic_background_job(true) at the start of wp-cron.php execution to move those transactions into New Relic’s non-web transaction view. In Datadog, set a custom DD_TRACE_CLI_ENABLED=true environment variable and tag CLI runs with DD_SERVICE=attowp-cli to keep them distinct from web transactions.

Setting Meaningful Alerting Thresholds

Generic alerting thresholds found in documentation are starting points, not targets. A WordPress site’s baseline metrics vary significantly based on its use case, server specifications, and traffic patterns. Here is a framework for setting thresholds that are actually useful.

Establish a Baseline First

Let your APM tool run for two weeks before setting any alerts. During this period, observe:

• The p50, p75, p95, and p99 response time distribution for your main page types
• The normal query count and total query time per page load
• Daily and weekly traffic patterns, most WordPress sites have significant diurnal variation
• The error rate baseline, some background processes generate acceptable errors that should not page anyone

With two weeks of data, set warning thresholds at 150% of your p95 baseline and critical thresholds at 200% of p95. This means you alert on genuine degradation, not normal variance.

Recommended Threshold Framework by Site Type

Alert Routing and Escalation

Not every alert warrants waking someone up. A useful three-tier routing structure:

• Warning, route to a Slack channel. Reviewed during business hours, no on-call required
• Critical (business hours), Slack with high-priority tag, assigned to on-call via PagerDuty or Opsgenie with a 30-minute response expectation
• Critical (outside business hours), immediate PagerDuty page if the condition persists for more than 5 minutes. Prevents alert fatigue from brief traffic spikes

Practical Workflow: From Alert to Fix

Understanding what the tools surface is only half the value. The other half is having a repeatable process for responding to what they show you.

Step 1: Triage in APM

When a performance alert fires, open your APM dashboard first. Check whether the elevated response time is isolated to a specific transaction type (one URL pattern, one AJAX action) or site-wide. Site-wide degradation that appeared suddenly suggests an infrastructure event, a server hitting memory limits, a MySQL table lock, or a caching layer failure. Isolated transaction degradation suggests a code change or a query that suddenly became expensive due to data growth.

Step 2: Narrow with Traces

Open the slowest traces from the time window when the degradation started. Look for the longest span in the flame graph. Is it MySQL? Narrow to the specific query using the Databases panel. Is it PHP execution time? The stack trace on the slow span shows which plugin hook or function is responsible. Is it an external HTTP call? Check the URL and see if the third-party service is experiencing an outage.

Step 3: Confirm with Query Monitor

Once you have a hypothesis from APM traces, open the affected page in your browser as an administrator with Query Monitor active. Reproduce the slow condition if possible. Query Monitor will confirm which specific query or hook call is responsible, show you the exact PHP caller, and give you the row counts and execution times that APM showed in aggregate.

Step 4: Fix and Verify

Apply the fix, add a missing database index, cache a transient, defer an external HTTP call, or optimize a WP_Query argument. Verify with Query Monitor that the query time has dropped and the row count is reasonable. Deploy to production and watch your APM dashboard: response time should return to baseline within minutes if the fix is effective.

Record the incident in a performance log: what degraded, when, what caused it, what the fix was. Over time this log becomes an asset, patterns emerge, recurring issue types point to systemic problems in your plugin stack or hosting configuration, and onboarding new developers is faster because the history is documented.

Common WordPress Performance Issues the Monitoring Tools Surface

After running APM tools across dozens of WordPress sites, certain patterns appear repeatedly. Knowing what to look for speeds up diagnosis significantly.

Object Cache Not Working

WordPress’s object cache stores the results of expensive database queries in memory so subsequent requests skip the database entirely. When it is not working, every page load queries the database for the same data. In APM, this shows as a high query count (often 50-200+ queries per page) with many identical queries, the same post meta values queried repeatedly, the same option rows fetched multiple times.

Query Monitor’s duplicate queries filter makes this immediately visible. The fix is installing a persistent object cache using a plugin like Redis Object Cache or W3 Total Cache’s object cache module, backed by a Redis or Memcached instance on your server.

Autoloaded Options Table Bloat

WordPress loads all rows from wp_options where autoload = yes on every request. Plugins often store large serialized arrays in autoloaded options, transient data, cached API responses, plugin settings with complex nested structures. When the autoloaded options payload exceeds a few hundred kilobytes, the initial database query that bootstraps WordPress becomes slow.

In APM, this appears as a slow query on wp_options at bootstrap time, very early in the transaction trace, before any page-specific logic runs. The fix is auditing and cleaning up autoloaded options, moving large plugin caches to their own tables or dedicated transients with short expiry.

Unindexed Post Meta Queries

The wp_postmeta table has an index on post_id but not on meta_key or meta_value. Plugins that query post meta by key to find posts matching a specific meta value perform full or partial table scans that become increasingly slow as the table grows. WooCommerce order meta, advanced custom fields queries, and membership plugin user capability checks are common offenders.

In APM and Query Monitor, these show as queries against wp_postmeta with high row counts and times above 50ms. The fix depends on the query: some are solvable by adding a meta index using a plugin like Index WP MySQL For Speed, others require switching to a different data model or using WP_Query’s built-in meta query optimization arguments.

Conclusion

WordPress performance monitoring tools give you the visibility to move from reactive firefighting to proactive optimization. New Relic delivers deep PHP transaction tracing and real user monitoring with strong alerting defaults. Datadog brings best-in-class composite alerts, log correlation, and infrastructure integration that ties your WordPress performance to your server health. Query Monitor gives every developer an immediate, zero-infrastructure window into what WordPress is actually doing per-request.

Start with Query Monitor to understand your site’s current performance profile and identify the obvious issues. Layer in New Relic or Datadog for production monitoring, set meaningful thresholds based on real baseline data, and build a response workflow that gets from alert to fix without wasted time.

For context on what these tools help you optimize, the WordPress speed optimization guide covers the most common performance wins in priority order. If your APM traces are pointing to database-level issues specifically, the WordPress database optimization guide goes deeper on index strategy and query architecture. For a broader foundation to monitor against, the complete WordPress performance optimization guide covers every layer from caching to server configuration.

Frequently Asked Questions

Is New Relic free for WordPress sites?

New Relic has a free tier that includes 100GB of data ingestion per month, full-stack observability, and one full-platform user. For most small to mid-size WordPress sites this is sufficient. Larger sites or teams needing multiple full-platform users will be on the usage-based paid plan.

Can I use Datadog on shared hosting?

No. Datadog’s PHP tracer requires installing a system-level package and running the Datadog Agent daemon, which requires root or sudo access on the server. On shared hosting you have neither. For shared hosting, Query Monitor is your best option for database and hook profiling without server access.

Does Query Monitor slow down my WordPress site in production?

Query Monitor adds minimal overhead when a user is not logged in as an administrator, it short-circuits its data collection early. When logged in as an admin, it does add noticeable overhead during data collection, which is expected for a profiling tool. The recommended production practice is to keep it inactive and activate it only during diagnostic sessions, or use the QM_DISABLED=true constant to disable collection while keeping the plugin installed.

What is the difference between APM and Real User Monitoring for WordPress?

APM instruments server-side PHP execution, it measures how long your server takes to build and deliver a response. Real User Monitoring (RUM) instruments actual visitor browsers, it measures how long it takes the visitor’s browser to download, parse, and render the page after the server response arrives. Both are necessary for a complete picture: APM tells you about server and database performance, RUM tells you about frontend rendering, JavaScript execution, and the impact of CDN and geographic distance on your real users.

How do I monitor WordPress cron jobs with New Relic or Datadog?

Both tools capture WP-Cron executions as PHP transactions. The key is tagging them separately from web traffic so they do not skew your response time metrics. In New Relic, call newrelic_background_job(true) at the start of a cron execution context. In Datadog, run WP-CLI-based cron with a distinct DD_SERVICE environment variable. This segments cron job performance into its own view and lets you alert on cron execution times independently of web request performance.