What you'll have when you finish
A WordPress admin that can answer five different operational questions without dropping into the database: did that email actually send, is that scheduled task actually running, who is hitting the site and from where, when did that user last log in, and what error is the site quietly writing to the debug log. Each tool captures specific data, stores it in a dedicated table or option, and renders it through an inline admin UI with filtering and export.
- Prerequisites: WordPress 5.0+, PHP 7.4+, and a basic AdminEase install. Some of these features add custom database tables on activation, which requires
CREATE TABLEprivileges (standard on virtually all WordPress hosts). - You'll need access to: a WordPress admin account with the
manage_optionscapability. Most of these tools are admin-only by design. - Time: 15 minutes to enable everything. The value comes later, when a problem appears and you have the data to diagnose it.
- Five tools, and the question each one answers
- The Email Log: capture, inspect, replay
- The Cron Viewer: scheduled tasks, execution history, pause and resume
- The Network Viewer: every request, with geo and bot detection
- Last Login Tracking
- The Debug Log: a safe tail viewer for wp-content/debug.log
1. Five tools, and the question each one answers
Before turning anything on, know which tool answers which question. They overlap only at the edges.
- Email Log answers "did that email actually get sent, what did it contain, and can I resend it?" Captures every
wp_mail()call: subject, recipients, body, headers, attachments, success or failure, triggering plugin. - Cron Viewer answers "what scheduled tasks does this site have, when do they next run, did they run successfully last time, and how long did they take?" Captures live cron data plus per-execution metrics.
- Network Viewer answers "who is hitting this site, from where, what are they requesting, and what response did they get?" Captures every non-static request with IP, country, user agent, browser, response code.
- Last Login Tracking answers "when did this user last log in?" One timestamp per user, surfaced as a sortable column in the Users list.
- Debug Log answers "what is WordPress writing to the debug log right now?" A read-only viewer of
wp-content/debug.logwith filtering and a download button.
Four of the five live under AdminEase › Debug. Last Login Tracking sits under AdminEase › Users › Tracking because it surfaces on the user-list screen rather than in a debug dashboard.
2. The Email Log: capture, inspect, replay
WordPress's wp_mail() function is the single biggest source of "wait, did that get sent" support tickets. Password reset emails, contact form submissions, WooCommerce order receipts, BuddyPress notifications, comment notifications, scheduled post publication notices, recovery mode emails. All of them go through wp_mail(), and by default WordPress logs nothing about what happens to them after that function returns.
The Email Log captures every wp_mail() call by hooking phpmailer_init (before send), wp_mail_succeeded (after success), and wp_mail_failed (after failure). It then writes a row to its custom database table {prefix}adminease_email_log with the timestamp, recipient, sender, subject, full message body (optional), headers, attachments, success/failure status, error message, detected email type (password_reset, user_registration, comment_notification, woocommerce_order, admin_notification, or custom), the user ID associated with the send, and the triggering context (which plugin or theme or WordPress core called wp_mail(), detected via PHP backtrace).
The log renders inline below the toggle as a paginated table (50 per page) with columns for time, status, type, recipient, subject, and an Actions column with an eye icon (opens a modal showing the email's HTML preview, plain text version, headers, and attachments) and a Resend button on failed entries. CSV export of the full log is available via a button. Bulk actions cover delete and resend-failed.
wp_mail() call from actually going out. The Email Log records them with status "blocked" so you can see what would have been sent. This is the right tool for a staging site that should never accidentally send a customer an order confirmation. It is exactly the wrong tool for a production site you forgot to flip off after staging. An admin-bar indicator turns red when sending is disabled, but verify before assuming.
3. The Cron Viewer: scheduled tasks, execution history, pause and resume
WordPress's scheduled-task system is unobservable by default. wp_get_schedule() and _get_cron_array() exist in PHP, but the admin shows nothing about them. The Cron Viewer surfaces two layers at once: the live cron array (what is scheduled right now and when it next runs) and an execution log (what actually ran, when, how long it took, and whether it succeeded).
Two tables render below the settings. The Scheduled Jobs table is built live from _get_cron_array() and shows every registered cron hook with its next-run time, recurrence schedule, arguments, whether a PHP callback is actually registered for it (sometimes WP-Cron has orphan entries), and an Actions column with view, run-now, pause, and delete buttons. Pausing a job stores it in the adminease_paused_crons option and removes it from the schedule, so it can be resumed later.
The Execution Log table is built from the custom {prefix}adminease_cron_viewer_log table, populated by hooks that fire at PHP_INT_MIN and PHP_INT_MAX around every registered cron action when DOING_CRON is true. Each entry records the timestamp, hook name, arguments, schedule, interval, execution time in milliseconds, peak memory usage, status (processing, success, failed, error), and any error message.
Filters at the top of the execution log let you search by hook name, filter by status, hide WordPress core entries (wp_ and recovery_mode_ prefixes), and hide Action Scheduler entries (which can be very noisy on WooCommerce sites). Manual run-now triggers via AJAX define DOING_CRON=true so the run is recorded with the same fidelity as a real cron-triggered one.
4. The Network Viewer: every request, with geo and bot detection
The Network Viewer is the most data-heavy of the five tools. It hooks init early in every request lifecycle and writes a row to {prefix}adminease_network_viewer_log with twenty-plus fields per request: timestamp, IP, country, hostname, request method, URI, request type (frontend, admin, AJAX, REST API, cron), query string, POST data (with sensitive keys auto-redacted), user agent, parsed browser name and device type, bot flag, referer, response code, request size, protocol, port, authenticated user ID and role, session ID.
Static asset requests (.css, .js, .jpg, .png, .gif, .svg, .ico, .woff, .ttf, .eot) are skipped to avoid drowning the log in trivia. Requests from IPs in the exclude list are skipped, which is the right place to put your own office IP so your admin browsing does not crowd out the data you actually want.
The UI renders as a single paginated table with columns for time, method, status code (color-coded by 2xx/3xx/4xx/5xx), request type, location (country flag), IP, path, and a visitor type icon (human or bot). Each row opens a modal with full request details organized into Request Info, Client Info, Response Info, User Info, and POST Data tabs. POST data is shown read-only in a textarea, truncated at 64KB with an indicator.
5. Last Login Tracking
The smallest feature in the set, and one of the most useful. It hooks wp_login, stores the current timestamp as user meta under the key _adminease_last_login, and surfaces the value as a sortable column in the Users list and as a section on individual user profile pages.
The Users column shows "2026-05-17 10:30 AM (2 days ago)" for users who have logged in, or "Never logged in" for accounts that exist but have never authenticated. Sortable both ascending and descending.
6. The Debug Log: a safe tail viewer for wp-content/debug.log
WordPress has a built-in debug log mechanism (set WP_DEBUG_LOG to true in wp-config.php and PHP errors get written to wp-content/debug.log). The AdminEase Debug Log feature does not change what gets captured (that is still WordPress core) but does give you a safe viewer that does not require SFTP to read.
The viewer renders the tail of wp-content/debug.log in a read-only textarea, with the number of lines you chose. Buttons let you clear the file (truncate to zero bytes), download it (file attachment with proper Content-Disposition), or refresh manually. The viewer reports file size, line count, warning count, and a percentage of the PHP memory limit so you can see when the log is growing dangerously large.
wp-config.php and shows an admin notice. The safeguard exists because trying to read a multi-gigabyte log file with PHP will out-of-memory the process and crash the admin. If you see the self-disable notice, download the log first, clear it, then re-enable debugging if needed.
Where to go from here
The five tools above are diagnostic infrastructure. They cost almost nothing to enable, and the value compounds the longer they run. The Email Log saves the next support call. The Cron Viewer saves the next "why didn't my scheduled post publish" investigation. The Network Viewer feeds the bot-blocking list. Last Login Tracking surfaces inactive accounts. The Debug Log catches the PHP warnings nobody noticed.
The companion tutorial "Update and Notification Control" covers the related question of how to manage email storms from a fleet of WordPress sites, including how to silence (or route) the notifications you do not want and tighten the recovery-mode contact email so critical errors actually reach the right person.
Frequently asked questions
How much storage do these features use?
Network Viewer is the heaviest because it captures every non-static request. On a site doing 10,000 page views per day, expect roughly 1 to 3 MB of log table growth per day depending on POST data volumes, capped by the max-entries setting (default 1000, which rolls over). Email Log varies hugely by site (a contact form might log 50 entries per day, WooCommerce might log thousands). Cron Viewer execution log on a typical site adds a few hundred entries per day. Last Login Tracking is one row per user, written on login. Debug Log file size depends entirely on what PHP errors your site generates.
Will these slow down my site?
The Network Viewer adds one database write per non-static request, which is measurable on very high-traffic sites (think tens of thousands of page views per hour) and unmeasurable on normal ones. Email Log writes on every wp_mail() call, which is irrelevant for most sites and adds latency only on sites that send dozens of emails per page load. Cron Viewer adds two writes per cron execution. Last Login Tracking adds one user-meta update per login. Debug Log is read-only and does not affect runtime. If a specific tool's overhead matters for your traffic, turn it off when you do not need it and on when you do.
Can other admins see this data?
Every UI panel and AJAX endpoint requires the manage_options capability, which by default is granted only to administrators. Editors, authors, contributors, and subscribers see none of it. The Last Login column on the Users list is visible to anyone with list_users (administrators by default; some role-management plugins extend this).
Are the log tables backed up by my hosting backup?
Yes if your host backs up the full database (most do). The AdminEase custom tables ({prefix}adminease_email_log, {prefix}adminease_cron_viewer_log, {prefix}adminease_network_viewer_log) are normal MySQL tables and get included in any standard mysqldump or managed-host snapshot. If you only back up specific tables, add these to your include list.
What about data privacy? Am I logging PII?
Yes. Email Log stores recipient addresses and full message bodies. Network Viewer stores IPs (which are PII in the EU under GDPR) and POST data. Last Login Tracking stores login timestamps. For GDPR compliance: document these logs in your privacy policy, set short retention windows (the auto-clear settings exist for this), and provide a deletion path on data subject requests. AdminEase does not auto-anonymize or hash this data; the responsibility for compliance rests with you. For HIPAA workloads, evaluate POST data redaction carefully or disable that capture entirely.
Can I see the data from outside WordPress, like in a monitoring tool?
The custom tables are normal MySQL and can be queried by anything that has database access. A simple Grafana panel or Metabase query against {prefix}adminease_email_log grouped by status gives you a delivery-health graph. The same approach works for cron timing and network traffic. For external alerting (paging you when failure rates spike), pipe the table contents to a metrics endpoint with a small custom export, or query the table from a cron job that posts to your monitoring service.