Cron Viewer Log gives you a live view of every WordPress scheduled task on your site, plus a full execution history with timing and memory metrics. It’s the easiest way to confirm that scheduled jobs are firing on time, find orphaned hooks left behind by removed plugins, and trigger any cron event on demand for debugging.
What this feature does
WordPress runs scheduled tasks through a system called WP-Cron. By default these jobs are invisible to administrators, which makes problems like missed daily digests or stuck plugin updates hard to diagnose. Cron Viewer Log surfaces two things side by side:
- Scheduled Jobs: the live list of every cron event currently registered on the site, including its hook name, schedule, next run time, and whether it’s a core, plugin, or orphaned event.
- Execution Log: a historical record of every cron job that has actually run since the feature was enabled, with the duration, memory usage, status, and any error message captured during the run.
From the same screen you can run a job immediately, pause or resume a recurring job, delete a job entirely, and clean up the execution log in bulk.
When you delete a plugin without using a clean-up routine, its scheduled hooks can stay registered in WordPress with no code listening to them. Cron Viewer flags these jobs as orphaned so you can remove them in one click.
How to enable it
- Open AdminEase › Debug. In the WordPress admin menu, click AdminEase, then switch to the Debug tab.
- Toggle Cron Viewer on. Find the Cron Viewer setting and flip the switch. The settings panel expands to reveal the sub-options.
- Choose your retention. Set Maximum Log Entries and Auto Clear Logs After to a window you’re comfortable with. Default is 1,000 entries kept for 7 days.
- Save settings. Scroll down and click Save settings. AdminEase creates the database table on first save and the dashboard reloads so the Cron Viewer screen mounts under the toggle.
Settings reference
| Setting | What it does | Default |
|---|---|---|
| Cron Viewer | Master switch. Off stops new execution-log entries from being recorded. The Scheduled Jobs view still works because it reads from WordPress directly. | Off |
| Maximum Log Entries | Hard cap on how many execution-history rows the table can hold. Oldest entries are pruned first when the cap is hit. Range: 100 to 100,000. | 1000 |
| Auto Clear Logs After | Maximum age of an execution-log entry before the hourly cleanup cron deletes it. Choose 1 Hour, 24 Hours, 7 Days, 30 Days, or Never. | 7 Days |
| Auto-Load Cron Viewer | When on, the Scheduled Jobs and Execution Log views fetch their first page as soon as the AdminEase dashboard opens. Off means you click Refresh manually. | Off |
Using the Cron Viewer
With the feature enabled and saved, a Cron Viewer panel appears on the Debug tab. It has two tables, one above the other.
Scheduled Jobs view
Lists every cron event currently registered on the site. Each row shows the hook name, schedule (e.g. hourly, daily, or a one-off timestamp), interval in seconds, next run time, and a source label indicating whether the job belongs to WordPress core, a known plugin, or is an orphan with no code listening to it.
Per-row actions:
- Run now: triggers the hook immediately and records the result in the Execution Log.
- Pause: unschedules the recurring job. AdminEase remembers the original schedule so you can resume it later.
- Resume: re-registers a paused job with its original schedule.
- Delete: removes the job entirely. Use this for orphaned hooks. Once deleted, only the originating plugin can re-create the job.
Execution Log view
A paginated history of every job that has actually run since the feature was enabled. Columns include timestamp, hook name, schedule, execution time (in seconds), memory usage, and status:
Completed means the job finished without errors. Processing appears for jobs that are currently running or didn’t report completion (typically a fatal error mid-run). Failed indicates the job threw an exception or returned a WP_Error.
You can select rows and bulk-delete them, or click a row to expand the full error message and arguments passed to the hook.
What happens behind the scenes
Cron Viewer Log uses one custom table, wp_adminease_cron_viewer_log, with indexes on hook, timestamp, and status. Capture happens through wrappers around do_action_ref_array registered for every scheduled hook, so each run records its start time, duration, memory usage, and final status.
An hourly cron event named adminease_cleanup_cron_viewer_logs enforces the Auto Clear Logs After retention window and the Maximum Log Entries cap. The cron is registered when the feature is enabled and unscheduled automatically when AdminEase is deactivated.
The Scheduled Jobs view is read live from the WordPress option cron on every refresh, so it always reflects the current state of WP-Cron rather than a cached snapshot.
Common workflows
Confirm that a daily digest is firing
Open the Scheduled Jobs view, find the hook (e.g. your_plugin_daily_digest), check that Next Run is in the near future, then look in the Execution Log for the most recent run with that hook. A green Completed badge confirms it ran. A repeating Processing badge usually means the job is timing out or fatal-erroring partway through.
Force a job to run right now
Useful when developing or debugging. Find the hook in the Scheduled Jobs view and click Run now. The job executes synchronously and a fresh row appears in the Execution Log when it finishes.
Clean up after a removed plugin
Switch to the Scheduled Jobs view and look for hooks with the Orphaned source label. Click Delete on each one. The hooks will not return unless you re-install the plugin that registered them.
Troubleshooting
Scheduled Jobs is empty
Highly unusual. WordPress core registers several jobs on every install. If the table is genuinely empty, your site has either disabled WP-Cron entirely (check Disable WP-Cron on the Performance tab) or the cron option in wp_options has been corrupted. Re-saving permalinks usually triggers WordPress to repopulate it.
Execution Log shows no rows after I enabled the feature
Cron Viewer only records runs that happen after the feature was enabled. Wait for the next scheduled event (or click Run now on a hook to trigger one immediately) and refresh.
A job runs constantly with status “Processing”
The job started but never reported completion, almost always because it hit a fatal error or PHP timeout. Inspect the row to see the captured error message. Common fixes: increase Max Execution Time on the Performance tab, lower the work the job does per run (process in batches), or check the hosting error log for fatals.
I deleted a job and it came back
The plugin that originally registered the hook re-creates it on every page load (a typical pattern for self-healing schedules). Either remove the plugin entirely or pause the job instead of deleting it.