Use Query Monitor first when the site still loads, and use WP_DEBUG when you need raw PHP errors, notices, and log files. Query Monitor gives you readable, request-level diagnostics inside WordPress. WP_DEBUG is the lower-level switch built into WordPress core, and it is officially described as a way to trigger debugging mode across WordPress [source: WordPress Developer Resources].
TLDR: Query Monitor is usually faster for finding slow database queries, bad hooks, HTTP API calls, template issues, and plugin conflicts. WP_DEBUG is better for catching PHP warnings, deprecated code, and fatal errors that need to be written to a log. For example, if a WooCommerce product page jumps from 900 ms to 3.2 seconds after a plugin update, Query Monitor may show 180 database queries from one extension, while WP_DEBUG may only show a harmless notice. Use both, but do not leave noisy debug output visible on a live site.
What Query Monitor does best
Query Monitor is a WordPress plugin built for practical troubleshooting. It adds a debugging panel to the admin bar and breaks down what happened during a single page request. That includes database queries, PHP errors, hooks, scripts, styles, REST API calls, HTTP requests, user capability checks, blocks, templates, and redirects.
This makes it very useful when the site is technically working but feels wrong. Maybe the admin area takes five seconds to load. Maybe checkout slows down only for logged-in customers. Maybe a custom template uses the wrong conditional logic. Query Monitor helps you see the request, not guess at it.
Its biggest strength is context. It does not just say a query was slow. It often shows which plugin, theme file, or hook triggered it. That saves real time. It drives me crazy when a site has ten active plugins and every one says the problem is “probably the theme.” Query Monitor cuts through that noise.
- Database queries: See slow queries, duplicate queries, and the caller behind them.
- PHP errors: View warnings and notices without digging through server logs.
- Hooks and actions: Check what runs on a request and in what order.
- Scripts and styles: Spot bloated assets and dependency problems.
- HTTP API calls: Find remote requests that delay page loading.
- Template loading: Confirm which theme file rendered the page.
Query Monitor is also mature and widely used. Its WordPress.org listing shows more than 200,000 active installations, which is a useful trust signal for a diagnostic plugin [source: WordPress.org].
What WP_DEBUG does best
WP_DEBUG is not a plugin. It is a constant set in the wp-config.php file. When enabled, it tells WordPress to show or record PHP warnings, notices, deprecated function messages, and other debugging output.
A common setup looks like this:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );This configuration turns debugging on, writes messages to wp-content/debug.log, and keeps those messages off the public screen. That last part matters. A live site should not expose file paths, plugin names, database hints, or stack traces to visitors.
WP_DEBUG is best when something breaks at the PHP level. White screen. Fatal error. Deprecated code after a PHP version change. A plugin calling a removed function. Query Monitor may not load if WordPress itself crashes early. WP_DEBUG can still write to a log if the server allows it.
Query Monitor vs WP_DEBUG: the real difference
The difference is simple: Query Monitor explains a request in a human-friendly way; WP_DEBUG records raw debugging information from WordPress and PHP.
| Task | Better Tool | Reason |
|---|---|---|
| Find a slow SQL query | Query Monitor | Shows timing, duplicates, and likely source. |
| Log PHP warnings | WP_DEBUG | Writes errors even when no admin panel is available. |
| Find a slow remote API call | Query Monitor | Shows HTTP requests and response times. |
| Catch deprecated code | WP_DEBUG | Displays or logs deprecation notices. |
| Debug page templates | Query Monitor | Shows loaded template files and conditionals. |
A practical troubleshooting workflow
Start with the least risky option. If the site loads, install Query Monitor on a staging site or during a controlled support window. Open the slow page while logged in as an administrator. Then check these panels first:
- Overview: Look at total page generation time, memory use, and database time.
- Database Queries: Sort by time and find repeated or expensive queries.
- HTTP API Calls: Look for external services taking more than 500 ms.
- PHP Errors: Check notices and warnings linked to plugins or the theme.
- Scripts and Styles: Look for too many files or obvious dependency errors.
If Query Monitor shows nothing useful, enable WP_DEBUG logging. Do not show debug messages to visitors. Use WP_DEBUG_DISPLAY as false. Then reproduce the issue once or twice, download the log, and turn debugging off when done.
Expect to waste time on false leads if you only use one tool. A slow checkout can be caused by a remote tax API, a bloated subscription plugin, a bad database query, or a PHP warning repeated hundreds of times. Query Monitor helps separate those causes. WP_DEBUG confirms code-level failures.
When WP_DEBUG can be risky
WP_DEBUG is safe when handled properly, but careless use can expose sensitive information. Debug messages may show server paths, plugin folders, theme files, class names, and sometimes fragments of data passed through hooks. On a public site, that is not acceptable.
Use this safer production-style setup only for short diagnostics:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );After testing, set WP_DEBUG back to false or remove the lines if your hosting stack manages debugging elsewhere. Also delete or protect the debug log if it contains sensitive data.
When Query Monitor can mislead you
Query Monitor is excellent, but it is not magic. It adds its own overhead. Usually that overhead is small, but on weak hosting or a very busy admin page, it can add noise. Do not judge final performance with Query Monitor active. Use it to identify causes, then disable it and measure again.
It also cannot diagnose every server problem. PHP memory limits, object cache failures, Nginx rules, cron problems, malware, and database server load may require hosting logs or command-line tools. If WordPress cannot fully boot, Query Monitor may not appear at all.
Best choice for common WordPress problems
- White screen: Start with WP_DEBUG and server error logs.
- Slow page: Start with Query Monitor.
- Plugin conflict: Use Query Monitor, then confirm with WP_DEBUG logs.
- Deprecated PHP warnings: Use WP_DEBUG.
- Slow admin dashboard: Use Query Monitor and check HTTP calls, queries, and hooks.
- Broken REST API request: Use Query Monitor, browser dev tools, and logs.
The serious answer is not “Query Monitor or WP_DEBUG.” The right answer is Query Monitor plus WP_DEBUG, used in the right order. Query Monitor gives fast, readable insight when WordPress still runs. WP_DEBUG gives low-level evidence when code breaks or errors need to be logged. Together, they reduce guesswork and make WordPress troubleshooting calmer, faster, and much less painful.