TLloancy Stack Trace records PHP fatals (memory exhausted, parse error, and similar), uncaught exceptions, wp_die failures, and exceptions that a third-party plugin caught so the site would not white-screen.
Each row stores:
- The last SQL that actually belongs to the crash (from
$wpdb, or from a small adapter when a plugin talks to MySQL outside$wpdb) - Memory usage, peak, and the configured limit
- File and line
- The plugin, theme, or core component most likely involved
- The request URL
Entries live in a dedicated table, under Tools Stack Trace. You can export CSV or clear the log.
This is not a debug.log viewer and not a live profiler. Generic log plugins tail PHP or WordPress logs. Stack Trace records why a request died: the SQL that belongs to the crash (including plugins that never set $wpdb->last_query), memory at the limit, and exceptions another plugin caught so the site would not white-screen. Typical case: an All-in-One WP Migration export that fails with “refresh and try again” while the real cause is a 128M SELECT or a full disk.
It is for the morning after: the site crashed, nobody was watching, and you want the cause.
Plugins that bypass $wpdb
Some exporters (All-in-One WP Migration among them) run SQL on $wpdb->dbh directly. $wpdb->last_query is then empty or already overwritten (cron, Action Scheduler). Stack Trace keeps SQL in memory via adapters and, on failure, can read that plugin’s own error-log last_query field. It does not edit third-party files and does not hook their export pipeline as a stage.
Automatic update failure emails (WordPress 7.2+)
A failed automatic plugin update already includes the fatal message, file, and line. Stack Trace adds memory and last SQL from the same loopback check, with a link to the full log.