# Query Monitor for WordPress and WooCommerce debugging

> Query Monitor is a developer tools panel for inspecting WordPress and WooCommerce requests, from database queries and PHP errors to hooks, HTTP calls, templates, and scripts. It is most useful for developers diagnosing request-specific behavior in a WordPress site.

**johnbillion/query-monitor** — The developer tools panel for WordPress and WooCommerce

- Repository: https://github.com/johnbillion/query-monitor
- Website: https://querymonitor.com
- Stars: 1,781 · Forks: 248
- Language: PHP
- License: GPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/johnbillion-query-monitor

## Query Monitor's request-level debugging scope

Query Monitor addresses a specific WordPress problem: a single request can involve database queries, PHP callbacks, templates, translation files, enqueued assets, HTTP requests, redirects, and permission checks that are difficult to trace from application code alone. It presents these details in a developer panel rather than asking developers to infer them from a page response. The intended audience is WordPress and WooCommerce developers working on plugins, themes, custom code, integrations, or site performance.

The plugin covers several layers of a request. Its database panel lists queries executed during the current request, affected rows, elapsed time, errors, duplicate queries, and slow queries. Queries can be grouped or filtered by type, component, or calling function. That makes it possible to connect a slow or repeated query with a plugin, theme, or function instead of reviewing an undifferentiated query log.

The scope is broader than database diagnostics. Query Monitor records hooks and actions, PHP warnings and notices, deprecated or incorrect WordPress usage, block content, rewrite information, scripts and styles, language files, HTTP API calls, capability checks, Multisite blog switches, and redirects. Its REST API and Ajax support add request-specific debugging for authenticated API requests and jQuery Ajax responses. This breadth is useful for a WordPress specialist, although it should not be confused with a general-purpose application performance profiler.

## How Query Monitor classifies request activity

The repository layout shows an extensible collection of collectors, dispatchers, PHP classes, TypeScript sources, and tests. That structure is consistent with a plugin that collects request events and presents them through multiple panels. The README describes component-based filtering as the central attribution mechanism. A component identifies the plugin, theme, or function responsible for an event, allowing the output to be narrowed to the part of the site under investigation.

The database view aggregates individual queries into groups by component, type, or calling function. This aggregation is more useful for triage than a flat list when the goal is to find the code responsible for the largest query volume or the slowest calls. The same attribution idea appears elsewhere. Hooks include action callbacks, priorities, and components. PHP errors include the component and call stack. HTTP API entries include response code, call stack, component, timeout, response size, and time taken.

Query Monitor also follows WordPress-specific context that ordinary server logs may omit. The Theme panel exposes the template filename, complete template hierarchy, requested template parts, load status, and body classes. The Request panel shows matched URL rewrite rules and query parameters, including custom variables. Scripts & Styles records handles, URLs, versions, dependencies, and dependents, including script modules added in WordPress 6.5.

Some requests have separate paths. Server-side redirects receive an `X-QM-Redirect` header containing the call stack. jQuery Ajax responses contain debugging information in headers and may write errors to the browser developer console. Authenticated WordPress REST API responses can contain debugging headers when the authenticated user has permission to view Query Monitor output. These mechanisms depend on the relevant WordPress request path. Query Monitor is not a transparent proxy for arbitrary traffic.

## Installing Query Monitor and starting a focused debug session

The README links to the Query Monitor plugin page at `https://wordpress.org/plugins/query-monitor/` and the project homepage at `https://querymonitor.com/`. The README does not give a command-line installation procedure, a Composer package installation command, or a WordPress CLI command. It therefore does not document enough installation detail to reproduce one here. The documented starting point is the WordPress plugin page, followed by activation in WordPress.

Once installed and activated, the first useful workflow is to reproduce one request and inspect the panel that matches the symptom. When diagnosing a custom code path, the README documents a logging action as a replacement for `var_dump()`:

```php
do_action( 'qm/debug', 'This happened!' );
```

This sends a message to the Logs panel. The documentation states that `qm/debug`, `qm/info`, `qm/notice`, `qm/warning`, `qm/error`, `qm/critical`, `qm/alert`, and `qm/emergency` correspond to PSR-3 levels. A `warning` or higher level triggers an admin toolbar notification. The example is deliberately small, but the operational rule matters: add the action near the event being investigated, reproduce the request, and then remove it after the cause is identified.

For timing, the README documents paired `qm/start` and `qm/stop` actions:

```php
do_action( 'qm/start', 'foo' );
my_potentially_slow_function();
do_action( 'qm/stop', 'foo' );
```

The `foo` identifier labels the timer in the Timings panel. This is basic profiling of code that the developer controls. It does not automatically explain all slow operations in WordPress, and the README does not claim that Query Monitor replaces a server profiler or browser performance tool.

## HTTP API, Ajax, and REST API debugging boundaries

Query Monitor is strongest when the code under investigation remains observable through WordPress mechanisms. For server-side HTTP requests, the README limits ordinary coverage to requests that use the WordPress HTTP API. It records response codes, time taken, response size, timeout information, call stacks, and component attribution, and it flags failed responses and responses without a `200` status.

Requests made through Guzzle require a separate path because they can bypass the WordPress HTTP API. The README states that Query Monitor can log Guzzle requests through optional middleware. That distinction matters when deciding whether a missing HTTP entry means no request occurred or means the request used an uninstrumented client.

Ajax and REST API behavior has narrower conditions. The Ajax feature is documented for jQuery Ajax requests on the page, with debugging information in response headers and errors in the browser developer console. For REST API requests, debugging headers are available when the request is authenticated and the authenticated user has permission to view Query Monitor output. Query Monitor is therefore not a universal way to inspect anonymous API traffic.

The plugin also records server-side redirects through the `X-QM-Redirect` header. This gives a browser or HTTP inspector a call stack for the redirect, but it does not replace application-level logging for redirects performed by intermediaries outside PHP.

## Alternative approaches and when they are a better fit

The closest general alternative for JavaScript behavior is the browser developer console. It can inspect network responses, console output, and browser-side timing without installing a WordPress panel. Query Monitor differs by retaining WordPress context, including the component responsible for a hook, query, template, asset, or server-side request. A browser console is the better choice when the question concerns browser rendering, client-side JavaScript, or response payloads that Query Monitor does not document.

For PHP execution time, a dedicated profiler or server-level tracing system may provide a different kind of evidence. Query Monitor's Timings panel requires explicit `qm/start` and `qm/stop` calls in the code being measured. That makes it useful for targeted measurements, but it will not reveal every expensive function unless the relevant instrumentation is added. The README presents basic profiling, not a complete sampling profiler.

For database work outside WordPress, database logs or application-specific monitoring can provide server-side history across requests. Query Monitor focuses on the current request and adds plugin and theme attribution. It is therefore a better fit for local WordPress debugging, while external tooling may be better for historical production analysis or infrastructure-wide visibility.

## Maintenance, licensing, and adoption costs

Query Monitor is not archived, and the repository's last push was on 2026-10-09. The listed releases include 4.0.7 on 2026-06-20, 4.0.6 on 2026-04-11, and 4.0.5 on 2026-04-10. The repository metadata specifies the default branch as `develop`.

The project is licensed under GPL-2.0-or-later in `package.json`, while the repository metadata identifies the license as GPL-2.0. That licensing matters when the plugin is distributed or incorporated into a WordPress installation, although this article does not provide legal advice. The repository includes source, collectors, tests, documentation, and build configuration, so adopting the plugin as a WordPress dependency should be distinguished from maintaining a fork or building the project from source.

The upgrade cost is not documented in detail. The repository has PHP tooling and a TypeScript build surface represented by `package.json`, `composer.json`, `vite.config.js`, and `src/index.tsx`, but the README and repository files do not provide an upgrade policy or compatibility matrix. WordPress plugin users should therefore verify compatibility with their WordPress, WooCommerce, PHP, and Multisite configuration before upgrading.

## Conclusion

Adopt Query Monitor when you need request-level visibility into WordPress or WooCommerce behavior, especially for query, hook, template, or HTTP debugging. Do not treat its timing data as a complete application profiler, and verify first whether your traffic uses the WordPress HTTP API or the included Guzzle middleware. Confirm that the authenticated user can access the relevant output and inspect the plugin in a staging environment before adding logging to production code.

## FAQ

### How do I install Query Monitor for WordPress?

The README points users to the WordPress plugin page at `https://wordpress.org/plugins/query-monitor/`, but the README does not document the exact activation steps or a command-line installation command.

### Can Query Monitor log HTTP requests made with Guzzle?

Yes, the README says Query Monitor can log Guzzle HTTP requests through optional middleware. This is separate from its standard coverage for requests made through the WordPress HTTP API.

### How do I record a timing measurement in Query Monitor?

Call `qm/start` with a timer name before the code you want to measure and `qm/stop` with the same name afterward. The README shows these actions in the Timings panel.

### Does Query Monitor require authenticated users for REST API debugging?

According to the README, REST API response headers contain debugging information when the request is authenticated and the authenticated user has permission to view Query Monitor output.

## Sources

- [johnbillion/query-monitor on GitHub](https://github.com/johnbillion/query-monitor)
- [License: GPL-2.0](https://github.com/johnbillion/query-monitor/blob/develop/LICENSE)
- [Project website](https://querymonitor.com)
- [README](https://github.com/johnbillion/query-monitor/blob/develop/README.md)
- [Releases](https://github.com/johnbillion/query-monitor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/johnbillion-query-monitor