A slow query is invisible until you can see it. Most shared and even managed hosting plans hide the one tool that actually tells you which queries are dragging your database down: the slow query log. We tested access to it across common hosting tiers to see who actually lets you look, and what you can do once you're in.
What the Slow Query Log Actually Shows
MySQL and MariaDB's slow query log records every query that takes longer than a configured threshold (commonly 1-2 seconds by default, though it's adjustable) along with the query text, execution time, and rows examined. It's the single most direct way to find the specific query — not just “the database feels slow,” but the actual SELECT or JOIN — that's responsible for a page timing out or a cron job stalling. Without it, diagnosing a slow WooCommerce catalog page or a bloated custom plugin query is guesswork.
What We Tested
Across a sample of shared, VPS, and managed WordPress hosting tiers, we checked three things: whether the slow query log is enabled by default, whether a customer can enable/view it themselves (via cPanel, a hosting dashboard, or SSH), and whether the threshold and log retention are configurable or fixed.
Shared Hosting: Usually Locked Down
On most budget shared hosting, the slow query log either isn't enabled at all, or it's enabled at the server level for the provider's own monitoring but not exposed to individual account holders. This isn't necessarily a support failure — on a shared MySQL instance serving hundreds of accounts, giving every customer raw log access is itself an operational and privacy consideration for the provider. But it does mean shared-hosting customers are typically stuck inferring slow queries from a plugin like Query Monitor rather than reading the actual server-side log.
VPS and Self-Managed: Full Access, If You Ask For It
On a VPS or dedicated server where you (or your host, on a managed VPS) control the MySQL configuration file directly, enabling the slow query log is a two-line change: setting slow_query_log = 1 and a long_query_time threshold in my.cnf, then restarting MySQL. This tier gave us the most control by far — full access to raw log files, adjustable thresholds down to fractions of a second, and no vendor gatekeeping. The tradeoff is that you're responsible for rotating and monitoring the log yourself; an unrotated slow query log on a busy site can grow large enough to matter.
Managed WordPress Hosting: Mixed, and Often Abstracted
Managed WordPress platforms frequently don't expose the raw slow query log at all — instead they surface a dashboard-level “slow query” or “performance insight” panel that summarizes flagged queries without giving you the underlying log file. This can actually be more useful for a non-technical site owner (readable summaries beat raw log parsing), but it's a real loss of granularity for anyone who wants to correlate a slow query against a specific request, plugin, or time window themselves.
Comparison Table
| Hosting Tier | Log Enabled by Default | Customer-Accessible | Threshold Configurable |
|---|---|---|---|
| Budget Shared | Rarely | Rarely, if at all | No |
| VPS (self-managed) | No (opt-in) | Yes, full access | Yes, fully |
| Managed VPS | Varies by host | Often via support request | Sometimes |
| Managed WordPress | Summarized dashboard, not raw log | Via dashboard panel, not raw file | Rarely exposed to customer |
Common Mistakes
- Assuming “no slow query log” means no slow queries. It means you can't see them — the queries are still running, you just have no visibility into which ones are the problem.
- Setting the threshold too high. A 2-second threshold on a page that should respond in 200ms will hide plenty of real problems. Lower the threshold, at least temporarily, when you're actively hunting a slowdown.
- Not rotating the log on self-managed servers. A slow query log that grows unchecked can itself become a disk-space and I/O problem on a busy site.
- Reading the log without checking rows examined. Execution time alone doesn't tell you whether a query is slow because of a missing index (high rows-examined) or because of server load at that moment — check both.
FAQ
Can I get slow query log access on shared hosting if I ask support?
Some providers will pull a filtered excerpt for you on request, but full self-service access is uncommon at the shared tier — if this matters to you, it's one of the clearer signals to move up to VPS.
Does enabling the slow query log slow the database down further?
The overhead is small at a reasonable threshold (1 second or higher), but very low thresholds on a high-traffic database can add measurable logging overhead — don't leave a sub-100ms threshold running permanently in production.
What's a reasonable threshold to start with?
Start around 1 second to catch genuinely slow queries without flooding the log, then lower it temporarily to a few hundred milliseconds when you're actively debugging a specific slowdown.
Is a plugin like Query Monitor a substitute for the server-side log?
It's a good complement — it shows per-request query timing inside WordPress — but it only sees queries triggered during page loads it's active for, while the server-side slow query log catches everything hitting the database, including cron jobs and other processes.
The Verdict
Slow query log access is one of the clearest lines between shared hosting and anything above it. If you're debugging a specific slow page or cron job and keep hitting a wall with plugin-level diagnostics, that's usually the sign you need server-level log access — which in practice means a VPS tier or a managed host that's willing to expose more than a summarized dashboard.
