How to Automate Joomla Maintenance with Scheduled Tasks

Maintenance that depends on somebody remembering is not maintenance

Session tables grow, logs accumulate, update checks need to happen. On most Joomla sites these jobs run only if an administrator remembers to run them, which means they quietly stop running the week everyone gets busy.

Joomla has shipped an answer since version 4.1: the Scheduled Tasks component. On Joomla 5 and Joomla 6 you will find it under System → Scheduled Tasks in the administrator area. It lets the CMS run routine actions automatically on a timed basis, much like server cronjobs, and third-party extensions can register their own task types on top of the ones core provides. The official user guide documents the component in three parts — how to schedule a task, how to choose a scheduler, and how to run tasks from the command line — and those three parts are also the correct order to think about the setup.

One distinction trips people up early, so it is worth stating plainly: the component separates what runs and when (the task and its execution rule) from what makes it run (the scheduler). You can configure a perfect task and it will never fire, because the scheduler side is still sitting on defaults. Handle them in that order.

What ships in the box

The Scheduled Tasks list already contains several built-in tasks when you first open it, some enabled by default. The user guide’s worked example is Session Data Purge, a routine that cleans up expired session data on a recurring basis — exactly the kind of unglamorous job that should never require a human.

The set of task types available when you click New depends on which plugins are installed. Core supplies a handful of routines, and extensions add their own: a backup extension will typically register a backup routine, a newsletter component a dispatch routine, and so on. If you install an extension specifically for its scheduler integration, enable the extension’s task plugin if it asks — a routine that never appears in the New task screen is almost always a disabled plugin, not a bug.

Three schedulers, one decision

The user guide describes three ways tasks actually get triggered, and you should pick exactly one.

The lazy scheduler is enabled by default and requires no setup. It rides along with normal site activity: when someone browses the frontend or works in the backend, Joomla checks whether any tasks are due and runs them during that visit. The trade-offs are what you would expect. On a quiet site, nothing runs — no visitors, no triggers. And the visitor whose request happens to coincide with a due task pays a small performance cost while it executes. For a low-traffic site where “roughly daily” is good enough, this is acceptable. For anything time-critical, it is not.

The web cron scheduler works from any server, including hosting that only offers URL-calling cronjobs. When you enable it in the Scheduled Tasks options, Joomla generates a Webcron Link — a URL containing a secret hash — and your hosting cronjob or an external cron service calls that URL on a schedule, typically with curl. Calling it every minute gives the scheduler one-minute precision; calling it less often makes tasks less punctual but does less work. Tasks run under your site’s own PHP version and user, and web cron includes built-in overlap prevention: it will not start a task that is already running.

Two caveats from the documentation. The link’s hash is a secret — anyone holding it can trigger your tasks, so keep it private. If it leaks, use Reset Access Key in the Scheduled Tasks options and update your cronjob with the new link. And because it is a web request, your host’s request time limits can cut long tasks short.

The command line is the option that needs no enabling at all. The scheduler:run console command is always available, has no web-server time limits, and involves no secret URL to protect. The guide’s recommendation is clear: when your cronjob can run on the same server as the site, use the CLI and skip the other two.

Whichever route you choose, the guide’s closing rule applies: only one scheduler should be active at a time. If you set up web cron or a CLI cronjob, disable the lazy scheduler and web cron in the options. Leave both web-based schedulers on and both will trigger tasks, and lazy will keep slowing the occasional visitor.

Setting a task’s timing

Open System → Scheduled Tasks, click the task’s name, and switch to the Edit Task tab. (Task-specific settings — which log file to rotate, which data to purge — live on the Advanced tab.)

The execution rule offers five shapes:

• Interval Minutes — a plain period. The guide’s example runs Session Data Purge every six hours by entering 360.
• Cron Expression (Advanced) — a full year view where you select hours, days of the month, months and days of the week. This is the tool for staggering: instead of every maintenance task firing at midnight, one runs at 02:10, another at 04:20, and a weekly job lands on Sunday morning.
• Interval Days — a period in days plus a time of day.
• Interval Months — a period in months, a day, and a time.
• Manual Execution — the task runs only when you press the yellow Run Task button in the list. Useful for jobs you want available on demand but never automated.

For most sites the honest recommendation is simple: use interval minutes for routine cleanup, and reach for cron expressions only when you need to spread load or pin a job to an off-peak window.

The CLI route in practice

The command from the documentation, adapted to a typical shared-hosting path:

/usr/bin/php /home/example/public_html/cli/joomla.php scheduler:run --all

Set this up as a command-type cronjob in your hosting control panel — not a URL-based one — running every minute, and append > /dev/null 2>&1 so cron does not email you the output of every run. Use the absolute path to your server’s PHP binary, and make sure it is a version your Joomla release supports; cron’s environment is not your login shell, and a wrong PHP path is the most common reason a working command suddenly “does nothing” from cron.

Three companion subcommands make day-to-day management easier:

• scheduler:run --id=5 runs the enabled task with ID 5 immediately, whether or not it is due — the quickest way to test a task end to end.
• scheduler:list shows each task with its ID, state and next run.
• scheduler:state enables, disables or trashes a task from the shell, handy for scripted maintenance.

The --all flag matters more than it looks. Without it, each invocation starts only the next due task, so tasks queue up behind each other. On a per-minute cron, always use --all.

One documented caveat: scheduler:run does not check task locks, so it can start a task that is still running in an earlier process — the web cron and lazy schedulers will not. If a task can legitimately outlast your cron interval, either make overlapping runs harmless (a purge routine usually is) or schedule it less frequently.

Verify before you walk away

Run the command manually over SSH first:

php cli/joomla.php scheduler:run --all

Joomla reports each task it ran and ends with a line like “Finished running N tasks.” Back in the administrator, the Last Run Date column in the task list should show fresh timestamps. Then check again the next day — a setup that works once and a setup that works on schedule are two different claims, and only the second one counts.

When tasks still don’t run

• Nothing executes at all. Which scheduler is active? A lazy scheduler on a quiet site runs nothing. A CLI cron with a wrong PHP path fails silently. A web cron link stops working after an access-key reset that the cronjob never picked up.
• Tasks fire late or in bunches. One-minute precision requires one-minute calls. Anything less frequent delays everything behind it.
• A long task dies halfway. That is the web request time limit. Move it to the CLI scheduler, which has none.
• The queue keeps growing. You are running scheduler:run without --all, so each run only drains one task.
• Visitors occasionally hit a slow page. The lazy scheduler is still enabled alongside your real scheduler. Turn it off.

Where this fits

Automating the boring half of Joomla upkeep is also the cheapest maintenance you will ever buy — it is one of the levers behind the long-run cost differences we describe in our total cost of ownership breakdown. And if a major version move is on your roadmap, audit your scheduled tasks as part of it: the Joomla upgrade planning checklist covers what to inventory before you change cores, and task routines belong on that inventory. If you would rather hand the whole setup — scheduler choice, cron configuration and task design — to someone who does this weekly, that is precisely what our Joomla development service covers.