Query Monitor is the developer tools panel for WordPress. It enables debugging of database queries, PHP errors, hooks and actions, block editor blocks, enqueued scripts and stylesheets, HTTP API calls, and more.
It includes some advanced features such as debugging of Ajax calls, REST API calls, user capability checks, and full support for block themes and full site editing. It includes the ability to narrow down much of its output by plugin or theme, allowing you to quickly determine poorly performing plugins, themes, or functions.
Query Monitor focuses heavily on presenting its information in a useful manner. Here's an example showing aggregate database queries grouped by the components responsible for them:
- Shows all database queries performed during the current request
- Shows affected rows and time taken for all queries
- Shows notifications for slow queries, duplicate queries, and queries with errors
- Shows aggregate query information grouped by type, component, or calling function
- Queries can be filtered by query type, component, or calling function
Filtering queries by component or calling function makes it easy to see which plugins, themes, or functions on your site are making the most (or the slowest) database queries.
- Shows all hooks fired during the current request, along with action callbacks, priorities, and components
- Actions can be filtered by component or name
- Shows the template filename and complete template hierarchy
- Shows all template parts that were requested, and whether they were loaded or not
- Shows the available body classes
- Fully supports block themes and full site editing (FSE)
- Shows PHP warnings, notices, stricts, and deprecated errors, formatted nicely along with their component and call stack
- Shows a visible warning in the admin toolbar when necessary
- Shows usage of "Doing it Wrong" or "Deprecated" functionality in the code on your site
- Shows blocks and associated information from post content and full site editing
- Shows information about matched URL rewrite rules for the request and corresponding query parameters
- Shows query variables and highlights any that are custom
- Shows all enqueued scripts and styles along with their handle, URL, and version
- Shows their dependencies and dependents
- Alerts you to any broken or missing dependencies
- Supports the script modules feature added in WordPress 6.5
- Shows you language settings and loaded text domains
- Shows you the requested MO, JSON, and PHP translation files for each text domain and which ones were loaded
- Shows all server-side HTTP requests (as long as they use the WordPress HTTP API)
- Shows the response code, call stack, component, timeout, response size, time taken, and other meta data
- Alerts you to erroneous responses, such as failed requests and anything without a
200response code
- Shows every user capability check that is performed, along with the result and any parameters passed along with the capability check
- Shows all calls to
switch_to_blog()andrestore_current_blog()on Multisite installations
- Whenever a server-side redirect occurs, Query Monitor adds an
X-QM-RedirectHTTP header containing the call stack, so you can use your favourite HTTP inspector or browser developer tools to trace where a redirect has come from
The response from any jQuery Ajax request on the page will contain various debugging information in its headers. Any errors also get output to the developer console. No hooking required.
Currently this includes PHP errors and some overview information such as memory usage, but this will be built upon in future versions.
The response from an authenticated WordPress REST API request will contain various debugging information in its headers, as long as the authenticated user has permission to view Query Monitor's output.
Read more about debugging REST API requests with Query Monitor.
- Shows the correct names for custom column filters and actions on all admin screens that use a list table
- Shows the state of
get_current_screen()and a few global variables
- Shows PHP information such as memory limit, error reporting levels, and values of various constants
- Shows MySQL or MariaDB information, including caching and performance related configuration
- Shows information about WordPress and the web server
- Shows version numbers for all the things
Debugging messages can be sent to the Logs panel using actions. This works as a good replacement for var_dump():
do_action( 'qm/debug', 'This happened!' );The logger is PSR-3 compatible, so you can use any of the following actions which correspond to PSR-3 log levels:
qm/debugqm/infoqm/noticeqm/warningqm/errorqm/criticalqm/alertqm/emergency
A log level of warning or higher will trigger a notification in Query Monitor's admin toolbar.
Read more about profiling and logging in Query Monitor.
Basic performance profiling can be displayed in the Timings panel using actions in your code:
// Start the 'foo' timer:
do_action( 'qm/start', 'foo' );
// Run some code
my_potentially_slow_function();
// Stop the 'foo' timer:
do_action( 'qm/stop', 'foo' );Read more about profiling and logging in Query Monitor.
- Shows any transients that were set, along with their timeout, component, and call stack
- Shows all WordPress conditionals during the current request, highlighted nicely
- Shows an overview at the top, including page generation time and memory limit as absolute values and as % of their respective limits
By default, Query Monitor's output is only shown to Administrators on single-site installations, and Super Admins on Multisite installations.
In addition to this, you can set an authentication cookie which allows you to view Query Monitor output when you're not logged in, or when you're logged in as a user who cannot usually see Query Monitor's output. See the Settings panel for details.
In order to do a few clever things, Query Monitor symlinks a custom db.php into your WP_CONTENT_DIR which means it loads very early. This file gets included before the database driver is loaded, meaning this portion of Query Monitor loads before WordPress even engages its brain.
In this file is Query Monitor's extension to the wpdb class which:
- Allows it to log details about all database queries (including ones that happen before plugins are loaded)
- Logs the full stack trace for each query, which allows it to determine the component that's responsible for the query
- Logs the query result, which allows it to display the affected rows or error message if applicable
If your WP_CONTENT_DIR isn't writable and therefore the symlink for db.php can't be put in place, Query Monitor still functions, but this extended functionality won't be available. You can manually create the db.php symlink if you have permission.
See the FAQ on the WordPress.org plugin page for Query Monitor.
I am accepting sponsorships via the GitHub Sponsors program. If you work at an agency that develops with WordPress, ask your company to provide sponsorship in order to invest in its supply chain. The tools that I maintain probably save your company time and money, and GitHub sponsorship can now be done at the organisation level.
In addition, if you like the plugin then I'd love for you to leave a review. Tell all your friends about it too!
Query Monitor is private by default and always will be. It does not persistently store any of the data that it collects. It does not send data to any third party, nor does it include any third party resources.
Query Monitor's full privacy statement can be found here.
Query Monitor aims to be fully accessible to all of its users. It implements best practices for web accessibility, outputs semantic and structured markup, uses the accessibility APIs provided by WordPress and web browsers where appropriate, and is fully accessible via keyboard.
That said, Query Monitor does not conform to the Web Content Accessibility Guidelines (WCAG) 2.0 at level AA like WordPress itself does. The main issue is that the user interface uses small font sizes to maintain a high information density for sighted users. Users with poor vision or poor motor skills may struggle to view or interact with some areas of Query Monitor because of this. This is something which I'm acutely aware of and which I work to gradually improve, but the underlying issue of small font sizes remains.
If you've experienced or identified another accessibility issue in Query Monitor, please open a thread in the Query Monitor plugin support forum and I'll try my best to address it swiftly.
Debugging is rarely done with just one tool. Along with Query Monitor you should be aware of other plugins and tools for debugging and profiling your website. Here are some recommendations:
- Block X-ray Attributes
- Code Profiler
- Debug This
- Decalog
- Laps
- Log HTTP Requests
- Rewrite Rules Inspector
- Snitch
- User Switching
- WP Crontrol
Query Monitor also has several add-on plugins which extend its functionality, and transparently supports add-ons for the Debug Bar plugin (see the FAQ for more info).
See also my list of WordPress Developer Plugins.
- Query Monitor WordPress Snippets for VS Code
- Buggregator
- Clockwork
- Meminfo
- memprof
- phpspy
- Psysh
- Ray
- Reli
- SPX
- Tinkerwell
- Xdebug
- XHProf
- Wonolog
- WP-CLI
profilecommand
Code contributions, feedback, and feature suggestions are very welcome. See CONTRIBUTING.md for more details.
Query Monitor's icon was designed by Tubagus Didin Asrori.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.