Query Monitor: The Developer Tools Panel Every WordPress Site Needs

When a page is slow, empty, or throwing intermittent warnings, guessing is expensive. Query Monitor (~1.8k stars) adds a full developer-tools panel to WordPress: database queries, hooks, HTTP API calls, redirects, PHP errors, block editor data, and more — from John Blackbourn, one of WordPress's most trusted plugin authors. Install it first on local and staging; it pays for itself the first time you spot a plugin firing 200 duplicate queries on a archive page.

What Query Monitor shows you

WordPress debugging often starts with WP_DEBUG logging to a file you forget to tail. Query Monitor surfaces runtime data in the admin bar and a structured panel:

• Database queries — count, time, caller stack, duplicate detection
• Hooks — which actions and filters ran, in what order, with timing
• HTTP API requests — outbound calls to Stripe, Mailchimp, CDNs blocking TTFB
• PHP errors and notices — including "doing it wrong" developer notices
• Redirects — unexpected canonical or plugin-driven redirect chains
• Scripts and styles — what enqueued on this request and from where
• Capabilities and user context — why an admin menu might be hidden

Who should install Query Monitor

• Theme developers building Sage, Timber, or custom PHP themes
• Plugin authors profiling activation overhead and admin pages
• Agencies inheriting slow client sites with unknown plugin stacks
• Anyone debugging ACF-heavy templates with expensive meta_query loops

When NOT to leave it wide open

• Production for all users — the panel exposes internals; restrict to developers or disable on public-facing roles
• As a replacement for proper logging — use server logs and APM for long-term production monitoring
• Performance optimization without measurement — QM shows symptoms; you still need a hypothesis and fix

Install

wp plugin install query-monitor --activate

Or install from Plugins → Add New. On Bedrock, prefer Composer or WP-CLI. Use it on local and staging; be careful exposing detailed panels on production for non-admins — many teams use environment checks to disable QM in production entirely.

What to look at first (debugging playbook)

1. Open a slow URL — check total query count and total query time in the admin bar badge.
2. Duplicate queries tab — N+1 patterns from themes calling get_post_meta in loops or ACF fields inside while (have_posts()) without object caching.
3. Slow queries — missing indexes, reckless meta_query with LIKE '%value%', or unbounded posts_per_page => -1.
4. HTTP requests — remote APIs blocking page load synchronously on every view.
5. Doing it wrong notices — deprecated API usage that will break on next WordPress major.
6. Hooks panel — unexpected plugins attaching expensive callbacks to the_content or wp_head.

Query Monitor vs other debugging tools

Pairing with the rest of your stack

• WP-CLI to install, activate, and script QM across environments
• Bedrock WP_ENV=development toggles for debug-friendly configs
• After stabilizing query performance, content teams still need efficient ACF editing — Quickfields Bulk Editor for ACF for spreadsheet bulk updates
• WPGraphQL projects still benefit from QM on the WordPress backend when resolvers trigger slow meta lookups

Gotchas

• Object caching — QM shows what happened this request; persistent object caches change behavior between requests.
• Admin vs front-end — query profiles differ; debug the URL users actually hit.
• QM adds overhead — acceptable in dev; do not benchmark production performance with QM active.
• Capability gating — ensure only trusted roles see the panel on shared staging servers.

FAQ

Free? Yes — open source on GitHub.

Works with multisite? Yes with network-aware panels.

Conflicts with other debug plugins? Possible — use one primary in-request debugger at a time.

Can I export query logs? QM focuses on interactive inspection; for persistent logging integrate server-level tools or custom SAVEQUERIES workflows alongside QM.

Does it slow down admin? Slightly — acceptable for debugging; disable when not actively profiling.

Case study pattern: the mystery slow archive

A Sage theme archive template loads 24 posts, each with five ACF text fields used in the card excerpt. Query Monitor shows 180+ database queries where you expected twelve. The duplicate queries panel reveals get_post_meta called per field per post inside the loop — classic N+1. Fix: batch meta retrieval, use object caching, or prefetch ACF with update_meta_cache patterns. Re-run QM until query count drops. Separately, editors bulk-fix the excerpt copy in Quickfields while you fix the theme — performance and content ops are parallel workstreams.

Repo

After you stabilize performance, content teams still need efficient ACF editing — see Quickfields Bulk Editor for ACF and GitHub. Pro: Quickfields Pro. Install QM via WP-CLI on every non-production environment by default so new team members inherit the habit.

Make Query Monitor part of your definition of done: no theme pull request merges without a QM screenshot or note confirming query count is acceptable on representative templates.

At ~1.8k stars, Query Monitor punches above its weight — indispensable on every serious WordPress codebase regardless of theme approach or stack.

Repo

github.com/johnbillion/query-monitor