Cron Jobs Nobody Documented

Things that run without anybody asking

Somewhere in your hosting is a list of scheduled tasks, running daily or hourly, set up at various points by various people.

Backups, cache clearing, a feed import, a report emailed to somebody, a database cleanup, an integration syncing with an accounting system.

Some are essential. Some were set up for a purpose that ended two years ago. At least one is probably failing every night and sending the notice somewhere nobody reads.

Almost no small business has ever looked at the list.

Why they matter

Because they are the part of the site that keeps working when nobody is watching, which cuts both ways.

A backup task that has been failing since March means you have no backups, and nothing about the site's behaviour indicates it.

A task that runs too often can consume enough server resource to slow the site or trip a hosting limit, which appears as an unexplained performance problem.

And a task nobody understands is a task nobody dares remove, so it accumulates alongside the ones that matter.

The point of an audit is not to become an administrator. It is to know what is running and whether it is working.

What you will find

• A backup task, possibly failing.
• A cache or cleanup task, usually fine.
• An integration with accounting, stock, or a supplier.
• A report emailed to somebody who has left.
• Something from a former agency, unrecognisable.
• A duplicate, where the same job was set up twice.

The fourth is the most common and the most harmless, and it is a useful indicator: if a task is emailing somebody who left in 2019, nobody has reviewed this list since then.

The failing backup

The finding worth doing this for.

Scheduled backups fail quietly for ordinary reasons: the destination filled up, credentials changed, a storage service was cancelled, or the account ran out of space.

When that happens the task usually still runs and still reports, and the report goes to whatever address was entered when it was created.

Which means the business believes it has nightly backups and has had none since some point nobody can identify.

Check the last successful run rather than the schedule, and confirm the destination actually contains recent files.

That is the difference between a backup arrangement and the appearance of one.

A worked example

A business audited their scheduled tasks for the first time and found seven.

Two were essential and working. One cleared a cache and was fine.

One emailed a sales summary to somebody who had left eighteen months earlier, at an address that no longer existed, generating a delivery failure every morning.

One imported a supplier feed that had been discontinued, failing nightly for around a year.

Two were duplicates of the same backup job, running an hour apart, one of which had been failing since a storage account lapsed.

The working backup was the other one, which was fortunate rather than designed.

The audit took forty minutes and the finding that mattered was that half their backup arrangement had been broken and nobody knew.

Fix where the output goes

The change that makes future failures visible.

Every scheduled task can report somewhere, and by default it reports to an address entered by whoever created it.

Redirect all of them to one address that a current person monitors, ideally a shared one rather than an individual's.

Then decide what you want reported: many tasks can be set to notify only on failure, which is considerably more useful than a successful message every morning that trains people to ignore the whole category.

A daily success email from seven tasks is noise. A single failure notice from one is information.

Do not delete what you cannot identify

The caution that keeps this safe.

Some tasks look meaningless and are load-bearing: a queue processor, a scheduled publisher, a payment reconciliation, or something a platform requires to function.

Disabling one of those produces a failure that appears days later and is difficult to connect to what you did.

Where you cannot identify a task, note it, ask whoever might know, and check whether the site behaves differently if it is paused rather than removed.

Pausing is reversible in a moment. Deleting means reconstructing a command nobody wrote down.

Write down what each one is

The output of the audit, and the reason it does not need repeating annually.

A short list: what it is, what it does, how often, where it reports, and who set it up.

Five columns, one line per task, kept with your other operational notes.

That turns the next audit into a comparison rather than an investigation, and it means the next person can tell whether something is expected.

Add a line whenever a new task is created, which is the discipline that prevents the situation this article describes.

The counter-case

Plenty of small sites have no scheduled tasks worth auditing.

A simple brochure site on managed hosting may have nothing beyond what the platform runs internally, and looking will produce an empty list and no findings.

Modern platforms also handle scheduling internally rather than through the hosting panel, so the list you can see may not be the whole picture, and asking your platform where its scheduled tasks live is a better question than reading the panel.

And there is a limit to how much a business owner should engage: understanding what runs is useful, and configuring scheduled commands is not a small business task.

Look once, fix the reporting, write down what is there, and leave the configuration to whoever maintains it.

The audit

1. Find the scheduled tasks list in your hosting panel.
2. Ask your platform whether it schedules separately.
3. Check the last successful run, not the schedule.
4. Confirm the backup destination holds recent files.
5. Redirect all reporting to a monitored address.
6. Set them to notify on failure only.
7. Write five columns per task and keep the list.

Step three is the one that matters, since a task that is scheduled and a task that is succeeding are different things and only one of them is visible from the list.

Recording how things work is covered in writing down how you do things.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.