A website CRON job resource checklist helps identify how scheduled tasks use server resources while they run. A CRON job is a time-based task scheduler that automates repetitive actions such as database backups, scheduled emails, and cache cleanup.
A repeatable audit helps administrators find tasks that overlap, run too often, repeat after failure, or create more logs and processes than expected. The checklist below focuses on the task schedule, the command it runs, its output, and the evidence available when a slowdown occurs. Learn more about CRON jobs in mybox.
Table of Contents
What to record for every CRON job
Start with one inventory of all scheduled tasks. Record enough information to identify each task without relying on memory or a short task name.
- The task name or description.
- The command or script that runs.
- The schedule and expected run frequency.
- The usual start time.
- The expected end time or normal run length.
- The files, database actions, emails, or other automated work involved.
- The location of output, error messages, and log files.
- The owner or administrator responsible for the task.
This inventory creates a baseline for later comparison. It also makes it possible to connect a resource spike with the task that was active at that time.
Check for overlapping jobs
Compare the start and expected end times of every task. Mark jobs that can run at the same time, especially tasks that perform backups, send scheduled emails, clear cache files, process uploads, or perform database work.
Overlap is important when several tasks compete for the same hosting resources. Review the schedule as a timeline rather than checking each job in isolation. A task that appears acceptable by itself may contribute to a slowdown when it runs at the same time as other scheduled work.
For each overlap, record:
- Which jobs run together.
- Whether the overlap happens during a known traffic peak.
- Whether the same files, database tables, or application processes are involved.
- Whether slowdowns or service errors occur during the overlap.
Review frequency and repeated execution
Check whether each task runs as often as the work requires. Excessive frequency can cause a task to start again before the previous work has finished or before the system has recovered from the earlier run.
Look for tasks that perform a large operation on a short schedule. Also check whether a task is scheduled at several points through the system, which can make its total frequency higher than expected. Record the intended frequency and compare it with the observed number of runs.
Find failed-task loops
Review task output, error messages, and run history for repeated failures. A failed task may continue to be triggered by its schedule, creating repeated processes, repeated database activity, or repeated log entries.
For each failure, record the time, command, exit result if available, error text, and whether another run started before the issue was resolved. A growing sequence of similar errors is useful evidence of a failed-task loop. Include the related log file and a short time range showing the repeated events.
Check command run time and timeouts
Compare the run length of each task with its schedule. Pay close attention to commands that remain active until the next scheduled start or that continue running during a period of high traffic.
Record the task start time, end time, and whether it completed, failed, or remained active. If the command has a timeout or another process-control setting, record that setting and the result when the task reaches it. This helps separate a single long-running task from repeated short runs.
A CRON job can also be used as a temporary workaround to terminate a specific process when a website script creates excessive server load. This should be treated as temporary while the underlying cause is addressed, not as a replacement for fixing the inefficient script or code. See the mybox process-termination CRON procedure.
Review logs and disk growth
Check where each task writes normal output and errors. Review whether a task appends output on every run and whether repeated failures are increasing the size of a log file.
Record the log file name, its size at the start and end of the review period, and the messages that repeat. Include the first and latest timestamps for the repeated entry. Log growth is especially relevant when a task runs frequently or enters a failure loop.
The wider website abuse audit in mybox also includes automated tasks, email activity, logs, and backups because these are useful points to review when investigating site activity and resource use. Use the website abuse prevention audit as a broader checklist.
Stagger schedules around traffic peaks
Map scheduled tasks against the periods when visitors are most active. Avoid placing several resource-heavy tasks in the same time window when the work can be spread out.
Staggering means moving tasks apart so that they do not all begin together. Record the current schedule, the proposed spacing, and the reason for the change. After the change, compare task run times, error messages, and website behaviour during the same traffic period.
Evidence to collect during a slowdown
When a CRON job appears to cause slow pages or service errors, collect evidence before changing several schedules at once. A clear timeline is more useful than a list of unrelated symptoms.
- The date and time when the slowdown or error started.
- The affected website action or service.
- The CRON job name and command active at that time.
- Start and end times for the active task.
- Whether other jobs were running at the same time.
- CPU, memory, process, disk I/O, or database connection symptoms observed during the event.
- Relevant task output, error messages, and log entries.
- Evidence of repeated failures, repeated starts, or a task that did not finish.
- Any schedule change made during the investigation and the time it took effect.
Keep the evidence tied to exact times. This allows the task schedule, logs, and service symptoms to be compared in the same sequence.
When to contact mybox support
Contact mybox support when the evidence shows recurring slowdowns or service errors but the responsible task is not clear, when a task remains active beyond its expected run period, or when repeated failures continue after the schedule has been reviewed. Include the task inventory, timestamps, commands, relevant output, and the schedule overlap you observed.