How to Use the Kinsta APM Tool

The Kinsta APM tool is a built-in performance monitoring feature inside MyKinsta. It records detailed timing data for PHP processes, MySQL database queries, and external HTTP calls on your WordPress site, so you can find exactly what is slowing your pages down without installing a third-party plugin. For the wider context on Kinsta, including plans, pricing, and the other performance tools available, see our Kinsta hosting guide.

This guide explains what the tool measures, how to enable it, how to read the transaction trace data it produces, what the numbers mean (and when they signal a real problem), and which WordPress plugins most commonly show up as the cause of slowdowns.

APM is one piece of a broader Kinsta optimization workflow; the full sequence (three-layer caching, when Redis helps, PHP worker tuning) is in our Kinsta WordPress optimization guide.

What Is APM?

APM stands for Application Performance Monitoring. In the context of WordPress hosting, an APM tool records how long different parts of a page request take to execute: which PHP scripts run, which database queries fire, and whether any external services (like payment gateways or API calls) are delaying the response.

Most performance tools (like Google PageSpeed or GTmetrix) measure the page from the browser side. The Kinsta APM tool works from the server side, which is where most WordPress slowdowns actually originate: slow plugins, unoptimised queries, or blocking API calls that happen before the page is even sent to the browser.

How to Enable the Kinsta APM Tool

The APM tool is disabled by default on all Kinsta sites. Only enable it when you are actively troubleshooting a performance issue. The tool adds overhead to every request, which slightly slows the site while it is running.

Step 1 - Log In to MyKinsta

Go to your MyKinsta dashboard, select the site you want to monitor, and navigate to the “Kinsta APM” section within that site’s area. Click the “Enable” button.

Step 2 - Set a Monitoring Duration

Choose how long the APM tool should run: 30 minutes, 1 hour, 2 hours, 3 hours, 12 hours, or 24 hours. For most debugging sessions, 30 minutes to 1 hour is enough to capture a representative sample of live traffic.

For performance testing (comparing before and after a plugin change), 30 minutes is sufficient. For intermittent issues that only appear at certain times of day, a longer window may be needed. Once the selected duration passes, Kinsta APM disables automatically.

Step 3 - Refresh the Dashboard

The APM dashboard does not update in real time. Click the “Refresh” button next to “Performance Monitoring” at the top of the APM page to load the latest data collected so far.

What the Kinsta APM Dashboard Shows You

Once data is collected, the APM dashboard breaks down your site’s activity into three key areas:

• Slowest PHP transactions: Lists the individual page requests (URLs) that took the most time to generate. A high execution time on a specific URL often points to a plugin running a heavy operation on that page, or a theme function with an inefficient loop.
• Slowest MySQL queries: Shows the database queries that took the longest to complete, along with the query text and which WordPress function triggered them. This is where you spot unindexed table scans, redundant meta queries, or plugin-generated queries that hit the database hundreds of times per page load.
• Slowest external HTTP calls: Captures calls your site makes to third-party services during a page request: payment processors, font providers, analytics endpoints, or social media APIs. A slow external call can add seconds to your server response time even if your own code is efficient.

Each panel ranks transactions from slowest to fastest, and clicking through shows a timeline view of how time was spent within that request.

Kinsta APM Quick Start: What to Check First

If you have just enabled APM and are looking at data for the first time, start here rather than reading every metric:

1. PHP response time - Look at the average PHP response time on the APM overview. Under 200 ms is healthy. Above 500 ms consistently means a plugin, query, or external API call is the likely culprit.
2. Top slow transactions - Click into the slowest transaction. It shows you a breakdown of where time is spent: PHP execution, MySQL queries, external HTTP calls. The longest bar is your first fix target.
3. Slow MySQL queries - If MySQL queries dominate, check which tables are being queried. A high number of identical queries often means missing caching (Redis Object Cache would help). A single very slow query usually points to a missing database index.
4. External API calls - If external calls (payment gateways, social embeds, font providers) are high, consider loading them asynchronously or removing unused external scripts.

You do not need to act on every number APM shows you. Focus on the single slowest component first, fix it, and re-run APM to confirm the improvement before moving on.

APM Performance Benchmarks: What the Numbers Mean

The APM data only becomes actionable when you know what counts as fast, borderline, or slow. These are practical thresholds based on WordPress hosting norms:

Total PHP Transaction Time

• Under 200ms: fast. WordPress is generating the page quickly; most of your remaining TTFB is network latency and not something APM can help with.
• 200-500ms: acceptable for complex pages (WooCommerce cart, account pages, pages with many shortcodes), but worth investigating. For simple blog posts or static pages, this is too slow.
• 500ms-1,000ms: slow. A plugin, theme function, or uncached database result is adding significant overhead on every load.
• Over 1,000ms: very slow. Visitors will notice. This level of PHP execution time almost always has an identifiable cause in the APM trace.

MySQL Query Time

• Under 50ms total: normal. A typical WordPress page fires 20-50 database queries; if total query time is under 50ms, the database is not your bottleneck.
• 50-200ms total: investigate the individual slow queries shown in the APM panel. One unindexed lookup can account for most of this.
• Over 200ms total: the database is the primary bottleneck. Common causes: missing indices on custom tables, WooCommerce order meta queries without caching, or a plugin running dozens of redundant queries per page.

External HTTP Call Time

• Under 200ms per call: acceptable for necessary third-party services.
• 200-500ms per call: noticeable impact. Consider caching the response server-side or lazy-loading the call after initial page render.
• Over 500ms per call: significant. If a third-party API is blocking PHP execution for half a second on every page load, it needs to be moved to an async queue or removed.

Your First 10 Minutes with APM: What to Look For

Many users enable the Kinsta APM tool but are unsure where to start. Here is a practical sequence:

1. Enable APM for 30 minutes during normal traffic. Click Refresh once to check if data is coming in.
2. Open “Slowest PHP Transactions.” Look at the top entry. If the total time is under 200ms, your PHP is fine : the problem is elsewhere (CDN configuration, browser rendering, or network). If it is over 500ms, keep reading.
3. Click into the slowest transaction. Look at the ratio: how much of the total time is PHP execution versus MySQL versus external calls? The biggest slice tells you where to focus.
4. If PHP dominates, look at the function call breakdown within the trace. Identify which plugin or theme function appears at the top. Deactivate that plugin and recheck : if the time drops, you have found the cause.
5. If MySQL dominates, open “Slowest MySQL Queries.” The query text will show you which table is being queried and roughly what triggered it. Look for queries from plugin tables (usually named with a prefix like wp_wc_ for WooCommerce or wp_rank_ for Rank Math).
6. If external calls dominate, open “Slowest External HTTP Calls.” The URL in each entry tells you which service is slow. Any call over 300ms that fires on every page load is a candidate for removal or caching.

After each change you make (deactivating a plugin, adding object caching, removing an external script), re-enable APM for another 30 minutes and compare the before and after numbers.

How to Read a PHP Transaction Trace

When you click into a specific slow PHP transaction in the APM dashboard, you see a detailed breakdown of that request. The most important numbers to look at:

• Total request duration: the full time from when the request hit the server to when a response was sent. If this is above 500ms regularly, something is blocking execution.
• PHP execution time: the time spent running PHP code. If this makes up 80 percent or more of the total request time, the problem is within WordPress itself (plugins, themes, or core functions), not an external service.
• MySQL query time: aggregate time spent waiting for database results. If MySQL time is high (over 200ms) but PHP time is otherwise low, the database is the bottleneck. APM shows the individual queries ranked by duration, with the query text and the calling function, which tells you exactly which plugin generated them.
• External HTTP call time: if this is high (over 500ms) while PHP and MySQL times are low, a third-party API is holding up the response. Common culprits: payment gateways, Google Fonts loaded server-side, abandoned API integrations, or analytics scripts that call home during PHP execution.

The ratio between these numbers tells you where to focus. PHP-heavy means a plugin or theme issue. MySQL-heavy means a query optimisation or caching issue. External call-heavy means a third-party dependency needs to be removed, cached, or moved to load asynchronously after the page renders.

Which WordPress Plugins Most Often Slow Sites (What APM Reveals)

Certain plugins appear repeatedly as performance culprits when users run the Kinsta APM tool. Knowing the common offenders before you look at the data helps you interpret results faster:

• WooCommerce: cart, checkout, and account pages are excluded from Kinsta’s full-page cache. These pages hit the database on every load. APM typically shows dozens of meta and option queries per request on WooCommerce pages with no caching layer. Redis object caching significantly reduces this.
• Elementor: stores large amounts of post meta for each page. On sites with many Elementor-built pages, the meta serialization queries can stack up, particularly on archive pages that load multiple posts.
• Yoast SEO and Rank Math: sitemap generation and schema computation can add noticeable overhead, especially on sites with thousands of posts. Typically shows as slow PHP transactions on sitemap URLs.
• Contact Form 7 and Gravity Forms: forms with complex conditional logic or large numbers of fields can add PHP execution time on pages that load them. Gravity Forms with email notifications that call external APIs can also appear as slow external HTTP calls.
• WP All Import / WP All Export: if left active after a bulk import, these plugins sometimes run scheduled tasks that fire during page loads, appearing as unexpected PHP slowdowns.
• WooCommerce Subscriptions: the renewal scheduler runs background processes that occasionally surface in APM as unexplained PHP spikes on non-WooCommerce pages. If APM shows slow transactions on admin-ajax.php without an obvious cause, check whether WooCommerce Subscriptions is active.
• TablePress: tables with many rows built without server-side pagination query the full dataset on every page load. APM shows this as a slow MySQL query retrieving far more rows than the page actually displays.
• Abandoned or inactive plugins: plugins that are installed but not needed often still run code on every page load (even deactivated ones sometimes leave cron jobs). APM occasionally reveals PHP time consumed by plugins that nobody remembers installing.

When APM points to a specific plugin, the quickest test is to deactivate it and recheck. If the transaction time drops, the plugin is the cause. You can then report the issue to the plugin author or find a lighter alternative.

Kinsta APM vs New Relic

If you are looking for New Relic integration in MyKinsta, it is no longer available. Kinsta removed the New Relic add-on in early 2022 and replaced it with the built-in Kinsta APM tool.

The key differences between the old New Relic integration and the current APM tool:

• Account ownership: New Relic required a separate New Relic account and had its own billing after Kinsta ended the free tier. The Kinsta APM tool is built into MyKinsta and included on all plans at no extra cost.
• Configuration: New Relic offered more configuration options and could be used across different hosting providers. The Kinsta APM tool is purpose-built for Kinsta’s WordPress hosting environment and is simpler to use.
• Data depth: New Relic provided more granular application-level tracing and had a richer dashboard. The Kinsta APM tool covers the most common WordPress debugging needs (PHP transactions, MySQL queries, external calls) without the complexity of a full APM platform.

For WordPress performance debugging on Kinsta, the built-in APM tool handles the majority of real-world issues. If your work requires a more detailed APM platform, you can integrate a third-party service directly at the server level, though this is rarely necessary for typical WordPress sites.

How to Act on the APM Data

Once you have identified a bottleneck, the fix depends on the type:

• Slow PHP transaction from a specific plugin: Deactivate the plugin temporarily and recheck. If the transaction time drops, the plugin is the cause. Look for an alternative or report it to the plugin author.
• Slow MySQL queries: Check which plugin or theme function triggered the query. Excessive meta queries are often caused by poorly-coded plugins that query post meta on every page load. Caching plugins or Redis object caching can reduce database hits significantly.
• Slow external HTTP calls: Load the resource locally where possible (self-host Google Fonts, for example), or lazy-load third-party scripts so they do not block the initial server response.

When Not to Use the APM Tool

There are a few situations where the APM tool is not the right choice:

• Non-WordPress sites: The APM tool is designed specifically for WordPress. Using it on a non-WordPress application running on Kinsta can produce misleading data.
• During high-traffic events: Because the tool adds server overhead, do not leave it running during a traffic spike or product launch. Enable it during normal traffic periods for a representative baseline.
• As a permanent monitor: For ongoing monitoring, use Kinsta’s built-in uptime and analytics dashboards instead. The APM tool is a diagnostic instrument, not a continuous monitoring solution.

Does the Kinsta APM Tool Cost Extra?

No. The Kinsta APM tool is included on all Kinsta plans at no additional cost. You do not need to install a third-party plugin or connect a separate account. It is built into the MyKinsta dashboard and available for every WordPress site on your account.

How Long Does the Kinsta APM Tool Keep Data?

The APM tool collects data only while it is actively enabled. Once the monitoring window ends (or you manually disable it), no new data is added. The data from that session remains visible in the dashboard for a limited period, but it is not archived indefinitely. If you need to compare performance before and after a change, enable APM, collect a sample, note down the key numbers, then re-enable it after making the change and compare the two sessions manually.

Kinsta APM and WordPress Multisite

The Kinsta APM tool works at the application level, not the individual subsite level. On a WordPress Multisite installation, the transaction data covers all requests to the application regardless of which subsite generated them. If one subsite has a slow plugin, the APM trace shows the PHP function responsible, but you need to cross-reference which subsite loads that plugin to isolate the cause.

Using Kinsta APM After a Site Migration: First-Hour Checklist

The first hour after migrating a WordPress site to Kinsta is one of the highest-value times to run APM. The migration process can introduce performance regressions that do not show up during basic smoke testing but will be visible in transaction traces: incompatible plugins that now run slower, database queries that relied on the previous server configuration, or object cache calls that need to warm up on the new environment.

Run the following APM checks within the first hour of the site going live on Kinsta:

1. Set APM to 5-Minute Sample Window

Use a short sample window immediately after launch to catch problems in real time. Browse the site as a regular visitor while APM is running: load the homepage, open 3 to 4 individual posts or pages, add a product to cart (WooCommerce), and load the admin dashboard. This generates the transaction data APM needs to surface bottlenecks.

2. Check Total PHP Transaction Time

Compare the average PHP transaction time on Kinsta against what you measured on the previous host. On Kinsta, a well-configured WordPress site typically delivers PHP transaction times under 200ms for cached pages and under 500ms for uncached dynamic requests. If total PHP time is higher than expected, open the slowest transaction traces and look for the plugins or functions consuming the most time.

3. Review MySQL Query Time

After a migration, some queries that ran efficiently on the previous host may perform differently due to different MySQL version, configuration, or InnoDB buffer pool settings. Look for any individual MySQL queries taking over 50ms in the transaction trace. These are candidates for query optimisation or missing database indexes.

4. Identify External HTTP Calls

If the previous host had different IP allowlisting or firewall rules, external API calls (payment gateways, marketing tools, third-party data providers) may now time out or take longer. APM makes these visible as external HTTP call time in the transaction trace. A call that appears in every page load trace is worth investigating first.

5. Enable Redis and Re-Run APM

If the site uses Redis Object Cache, enable it after the migration and re-run APM with a fresh 5-minute window. Compare MySQL query counts before and after: a working Redis configuration typically reduces the number of database queries per page load by 30 to 70 percent on dynamic sites. If the numbers do not change, Redis may not be connecting correctly. See our guide on how to use Redis Object Cache on Kinsta for connection verification steps.

Kinsta APM vs Query Monitor

Query Monitor is a free WordPress plugin that shows you database queries, PHP errors, and hook performance from inside the WordPress dashboard. It is a useful complement to Kinsta APM but works differently.

Use Kinsta APM first: it gives you a time-series view across all traffic rather than just one page load in your browser. Once APM points you to a specific plugin or query, switch to Query Monitor on a staging site to drill into the exact SQL or PHP hook causing the slowdown. The two tools are complementary, not competing.

Final Word: How to Use the Kinsta APM Tool

The Kinsta APM tool gives you server-side timing data that front-end tools cannot provide. Enable it when you notice unexplained page slowdowns, use the PHP transaction and MySQL query data to isolate the cause, then disable it once you have collected enough data. It is free on all Kinsta plans and takes less than a minute to activate. For account security alongside performance monitoring, you should also secure your MyKinsta account with 2FA. For deeper performance work, combining APM findings with Kinsta CDN optimisations covers both server-side and delivery-side bottlenecks. If the APM reveals heavy database query load, consider enabling Redis Object Cache on Kinsta to reduce repeated query overhead. If the APM reveals PHP errors rather than performance issues, enabling WordPress debug mode in MyKinsta shows the specific file and line number of the issue.