The reason cron jobs rot is that nothing records what happened — a job that started failing three weeks ago looks exactly like one that is working. Storing the output, duration and exit code per run, with a success rate rolled up, turns that into something readable. run_now is the other tool that earns its place: the normal way to test a cron job is to wait, and waiting is how a broken schedule reaches production. Be clear about what this is: it executes shell commands on the host, so it is exactly as powerful as the account it runs under.
A cron job manager with ten tools covering the job lifecycle and, importantly, its execution history: schedule, modify, pause, trigger manually, and read logs and success rates.
- Jobs created with a schedule and a shell command, updated in place rather than recreated, and deleted along with their run history.
- pause_resume disables a job without deleting it, which is what you want before a maintenance window.
- run_now executes immediately bypassing the schedule — the tool that makes a new job testable before you wait for its first trigger.
- get_status returns last run, next run, success rate and average duration, so a job's health is a number rather than an impression.
- get_logs returns a job's execution output with duration and exit code, and list_executions covers recent runs across every job.
A host to schedule on. The jobs are shell commands, so they run with whatever permissions the server has.
One command — npx -y @supernova123/cron-scheduler-mcp-server