Zactonz Cron Doctor

v1.0.0

See whether your cron jobs really run, and fix the ones that do not.

cPanel 102+ (Jupiter)Root to installPHP 7.4+ Updated 30 Sep 2026

Requirements

Component Minimum
Operating system Any that cPanel itself supports
cPanel & WHM 102 or newer, Jupiter theme
PHP 7.4 or newer for the interface, with mbstring and json
Shell Any POSIX shell for the runner; /bin/sh is used by default
Access Root, over SSH or WHM Terminal, to install

Operating system#

There is no operating-system-specific code in the plugin, so it runs wherever cPanel does. cPanel currently supports AlmaLinux OS, CloudLinux, Rocky Linux and Ubuntu; cPanel's own system requirements are the authority on which versions of each are supported at any moment, and that list changes as distributions reach end of life.

Windows is not supported, because cPanel itself does not run on it.

Cron Doctor was verified on cPanel 11.138 (x86_64). What it actually depends on is a POSIX shell and PHP; everything else is optional and described below.

Running commands#

To change a crontab, the cPanel interface needs PHP's proc_open, and a working crontab command must be reachable.

On a cPanel server /usr/local/bin/crontab is the one that works for an account; the raw /usr/bin/crontab exists but cannot read /var/spool/cron/<user> from inside the account's jail. Cron Doctor does not assume either: it tries each candidate and uses the first that actually returns the crontab.

Where commands cannot be run at all, the plugin falls back to read-only mode. Every check still runs and every finding still explains what to change, but nothing is written and the buttons that would change something are not shown. This is stated at the top of the dashboard rather than left to be discovered.

Optional commands#

flock, timeout and setsid are used when present and none of them are required.

  • flock gives locking that the kernel releases when a process dies, so a stale lock is impossible. Without it, locking falls back to an atomic directory with a process id inside, and a lock left by a killed run is broken by the next one.
  • timeout or setsid allow a job that reaches its time limit to be stopped together with any background work it started. Where neither exists, the runner stops the job process itself and records that background work may have survived, so the interface can say so honestly. Time limits are off by default, so this only matters if you turn one on.

On a stock AlmaLinux or CloudLinux cPanel server all three are present at /usr/bin/.

Per-account storage#

Everything belonging to an account lives in ~/.zactonz/zcd, created with owner-only permissions. Captured output is kept there, never inside a document root and never served as a file. How much is kept is configurable per job, and it can be deleted from the interface at any time.