Monitoring WordPress with InitTop: From MySQL Monitoring to Full-Stack Observability

The previous post covered installation and basic features. This post dives into v1.1.0 — the version that elevates InitTop from a “viewing tool” to a true profiler and action center for WordPress. Topics include Query History, Export Slow Log, JSON mode, and how to integrate InitTop as a piece of a full-stack observability system.

WordPress + MySQL: A Ubiquitous Pair with Hidden Bottlenecks

WordPress powers over 40% of the web, and the vast majority run on MySQL or MariaDB. The problem: when a plugin malfunctions, transient cache bloats, or a cron job fires an unoptimized query, there is no way to know exactly what is happening using just htop or mysql -e "SHOW PROCESSLIST".

InitTop v1.1.0 solves this by providing:

• Real-time processlist with color-coded danger levels.
• Query History — detects repeated queries within the session.
• Inline EXPLAIN — optimize queries directly in the terminal.
• Kill query — rescue a frozen site without restarting MySQL.
• Export slow log — capture evidence for later analysis.
• JSON mode — integrate with cron, log parsers, or monitoring stacks.

What’s New in InitTop v1.1.0?

Before diving into WordPress use cases, here is the full list of new features in v1.1.0:

Real-World Scenario: WordPress Suddenly Slows Down

Imagine a WordPress site suddenly freezes, with the admin panel unreachable. SSH into the VPS and run InitTop.

Step 1: Observe the Overview

The first line shows:

MySQL 8.0.36  |  Uptime 12:34:56  |  MaxConn 151  |  SlowAt >=1.0s  |  QPS  245.3  ▁▂▃▄▅▆▇█

QPS suddenly jumps from 15 to 245? The sparkline shows a final “█” column — a sign of a traffic spike or a process bombarding the database.

Step 2: Detect the Culprit via Color Coding

In the processlist, one row stands out in RED bold:

PID     USER    DB              CMD     TIME    STATE           QUERY
48291   wp_user wp_database     Query   8.2     Sending data    SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'product' AND ...

TIME = 8.2 seconds, colored red. This is the query choking the system. But it is only one query. Press H — Query History — and see:

 COUNT   SLOW   QUERY
   147     12   SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'product' AND ...

This query has appeared 147 times in the session, 12 of them flagged as slow. This is not a one-time error — a WooCommerce plugin or a theme snippet is running inside a loop. Repeated queries are the classic signature of the N+1 query problem in WordPress.

Step 3: EXPLAIN Directly in the Terminal

Navigate to that query and press e. InitTop displays an overlay:

 EXPLAIN output - any key to close
  select_type=SIMPLE  type=ALL  possible_keys=NULL  key=NULL  key_len=NULL  ref=NULL  rows=45231  Extra=Using where

type=ALL and key=NULL — a full table scan on wp_posts with 45,231 rows. The plugin is querying without using an index. A composite index on (post_type, post_status) is needed, or the query logic must be optimized.

Step 4: Temporary Rescue with Kill Query

While waiting for a code fix, the site should not remain frozen. Select the query and press K (capital). InitTop sends KILL QUERY 48291. The query stops immediately, CPU drops, and the site recovers.

Step 5: Export Evidence for Later Analysis

Press W to export all current slow queries to a file:

# InitTop export — 2026-07-01 14:32:15  QPS=245.3
# Slow threshold: 3s
# Processes: 47  Slow: 12
# PID=48291  USER=wp_user  DB=wp_database  TIME=8.2s  STATE=Sending data
SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'product' AND ...

This file is appended to inittop_slow.log (or the path specified via --log-file). It can be used to:

• Send to developer/theme support.
• Analyze with pt-query-digest if needed.
• Save to a ticket for regression tracking after the fix.

Periodic Monitoring with JSON Mode

InitTop’s interactive TUI is powerful when online. But to make InitTop part of a monitoring system, JSON mode is essential.

Run Periodic Snapshots via Cron

# Every 5 minutes, write a JSON snapshot to log
*/5 * * * * MYSQL_PWD=your_password /usr/local/bin/inittop -u root -S /run/mysqld/mysqld.sock --json --json-count=1 --interval=2 >> /var/log/inittop.jsonl 2>/dev/null

Each line of output is a complete JSON object:

{
  "ts": "2026-07-01T14:35:22",
  "version": "8.0.36",
  "uptime_sec": 45231,
  "qps": 245.3,
  "connections": {
    "connected": 47,
    "running": 12,
    "slow": 3,
    "locked": 0
  },
  "buffer_pool": {
    "size_mb": 1024,
    "hit_pct": 98.5,
    "used_pct": 82.3
  },
  "processes": [...]
}

With this data, it is possible to:

• Parse with Python/Node to send alerts via Telegram/Slack when slow > 5 or hit_pct < 90.
• Push to Loki or Elasticsearch if a log stack already exists.
• Draw simple charts with a Python matplotlib script — no complex Prometheus setup required.

Simple Alert Script

#!/bin/bash
# /usr/local/bin/inittop-alert.sh
export MYSQL_PWD="your_password"
/usr/local/bin/inittop -u root -S /run/mysqld/mysqld.sock --json --json-count=1 | python3 -c "
import sys, json
data = json.loads(sys.stdin.readline())
slow = data['connections']['slow']
locked = data['connections']['locked']
hit = data['buffer_pool']['hit_pct']
if slow > 3 or locked > 0 or hit < 90:
    print(f'[ALERT] InitTop: slow={slow}, locked={locked}, buffer_hit={hit}%')
"

Running this script via cron every minute creates an automated alerting system without installing any additional agents.

Full-Stack Observability: Where Does InitTop Fit?

“Full-stack observability” sounds fancy, but for self-hosted WordPress, it simply means seeing the entire chain from request to response. InitTop occupies the database layer.

Three-Tier Monitoring Model for WordPress

When all three are combined, an issue can be traced as follows:

1. Goaccess shows a spike of 500 errors from IP X.
2. PHP-FPM log shows request timeouts after 30 seconds.
3. InitTop shows a query from user wp_user in Sending data state for 28 seconds on wp_postmeta — a full table scan.
4. EXPLAIN confirms a missing index on meta_key.
5. Kill query brings the site back to life; export log captures evidence for the fix.

That is real full-stack observability — no Datadog, no New Relic, just a terminal and logs.

Buffer Pool and Connections: Read Correctly to Act Correctly

Beyond the processlist, InitTop v1.1.0 displays two critical metrics every WordPress admin should understand:

Buffer Pool Hit Rate

This ratio indicates how often MySQL reads data from RAM (buffer pool) instead of disk. For WordPress:

• ≥ 99%: Excellent. The buffer pool is large enough for the entire dataset.
• 95–98%: Acceptable. May need to increase innodb_buffer_pool_size for larger sites.
• < 95%: Warning. Disk I/O is the bottleneck. WooCommerce with thousands of products will be very slow.

InitTop displays the hit rate as a color-coded progress bar: green → yellow → red. No need to memorize numbers — the color tells the story.

Buffer Pool Used %

If this bar fills up (>90%), MySQL starts evicting old data from RAM. WordPress sites with many plugins often have large wp_options and wp_postmeta tables — easy to fill the buffer pool.

Connections

• Connected: Current number of connections. If near max_connections (usually 151), WordPress will throw “Error establishing a database connection”.
• Running: Number of queries currently executing. High Running with low QPS means queries are hanging.
• Slow: Number of queries exceeding the threshold. When this flashes red, action is needed immediately.
• Locked: Number of queries waiting on table locks. MyISAM or unoptimized ALTER TABLE operations can cause lock cascades.

Mouse Support: Even the Terminal Can “Click”

A small but highly practical addition in v1.1.0: InitTop supports mouse input on terminals such as iTerm2, GNOME Terminal, and even Windows Terminal over SSH.

• Click a row to select that query — no arrow keys needed.
• Double-click to auto-EXPLAIN the selected query.

This is especially useful during screen-sharing with clients or colleagues. They see the exact query being clicked, then double-clicked for EXPLAIN — highly intuitive.

InitTop vs. Other Tools: A WordPress Perspective

InitTop does not replace Query Monitor — it complements it. When WordPress is alive, Query Monitor helps debug themes and plugins. When WordPress is dead because of the database, InitTop is the only tool that needs to be opened.

Recommended Workflow for WordPress Admins

This is the workflow applied to Init Manga sites and client WordPress sites:

1. Install InitTop immediately when deploying a server (already integrated in InitOps).
2. Keep the TUI running in tmux/screen during maintenance or major updates.
3. Set up cron with --json to record snapshots every 5 minutes.
4. Write a simple parser script to alert when slow queries > 3 or buffer hit < 95%.
5. When an incident occurs:
   • Open InitTop → observe the colors.
   • Press H to view repeated queries.
   • Press e to EXPLAIN the suspicious query.
   • Press K to kill if immediate rescue is needed.
   • Press W to export the log before exiting.
6. After the incident: use the slow log to add indexes, optimize plugins, or contact the developer.

Conclusion

InitTop v1.1.0 is no longer just a MySQL “viewing” tool. With Query History, Export Slow Log, inline EXPLAIN, Kill query, and JSON mode, it has become a true profiler and action center for WordPress.

Most importantly, it retains the Init HTML philosophy — self-contained, minimal dependency, runs on any terminal. No complex monitoring stack is needed just to find out why a WordPress site is freezing.

If InitOps was used to deploy the server, InitTop is already ready. If not, one command line is all it takes.

Quick Install Command

curl -sSL https://inithtml.com/inittop/install.sh | bash

v1.1.0 Quick Reference

• ↑ / ↓ — Navigate between processes.
• K — Kill the selected query.
• e — EXPLAIN the selected query (SELECT only).
• / — Filter the processlist.
• ESC — Clear filter or close overlay.
• s — Cycle sort column.
• p — Pause / resume auto-refresh.
• r — Force immediate refresh.
• W — Export slow queries to log file.
• H — Open Query History overlay.
• C — Clear Query History.
• ? — Open help screen.
• q — Quit InitTop.