Setting up a cronjob: guides for common systems

“Cronjob.de – Reliable Cron” in the WordPress directory: shows the address of your wp-cron.php, opens the cron job pre-filled and switches off the cron on page visits.

Scheduled tasks and message queue without a CLI worker: upload the plugin, open a link, save. The admin worker then switches itself off.

No SSH, no crontab, and your host's cron manager is not enough? This is how a script on your web space still runs reliably on a schedule.

Windows has no cron. This is how you schedule tasks with Task Scheduler and schtasks – and when a call from outside is the better way.

All-Inkl offers cronjobs in its KAS panel, but not in every plan. Here is how setup works there and when an external call is worthwhile.

STRATO offers cron jobs only once, daily, weekly or monthly, and not in every package. Anything more frequent needs a call from outside.

IONOS offers cronjobs but recommends at least five minutes between runs. For minute-precise work or a readable log of every call, add an external service.

The Host Europe WebHosting packages have no cronjobs at all, and the scheduler in the KIS does not accept an address. A call from outside solves both.

WP-Cron only runs when somebody visits the site, so scheduled posts and backups simply do not happen. Our free plugin sets up the cronjob with you.

Otherwise Contao runs scheduled tasks on a visitor page view. A fixed interval takes the randomness out.

By default Drupal triggers its cron on page views. Without visitors tasks pile up, with many visitors the check costs time for nothing.

By default Joomla wakes its task scheduler on page views. With Web Cron it runs at a fixed interval instead, independent of visitors.

Without cron Moodle stands still: no mail, no reports, no backups. Without command line access, calling by address is the way.

In webcron mode Nextcloud handles exactly one background job per call. The interval decides how much gets through.

Without background archiving Matomo only computes reports when somebody opens them, and makes them wait.

Dolibarr scheduled jobs do not run by themselves – without a trigger from outside the module stays idle.

Without a schedule phpList only sends while a browser window stays open, and stops when you close it.

Without a daily call the recurring transactions, automatic budgets and exchange rates are missing.

Scheduled workflows on GitHub often start late, get dropped under load and are disabled in public repositories after 60 days. Cronjob.de starts them on time through the API.

Gambio handles image processing, currency rates and the sitemap through scheduled tasks. Each has its own address that somebody has to call – Gambio recommends every minute for that.

Shopware 5 runs its cronjobs through the address /backend/cron and protects them with a key. For Shopware 6 there is our free plugin.

JTL-Shop only works through its queue after a certain number of shop page views. At night it therefore just sits there.

WooCommerce's Action Scheduler rides on WP-Cron and therefore on your visitors. Orders and subscriptions get stuck as a result.

Doofinder searches its own index of your catalogue. If it is not rebuilt, your search finds articles that no longer exist.

Whether last night's backup ran usually shows only when you need to restore. One line makes it report every run, result included.

WP-Cron only runs on visits and does not tell you when it stalls. A small plugin checks in every hour – if it goes quiet, you know.

An error workflow reports failures during a run – but not when the workflow never starts. One HTTP node at the end closes the gap.

Scheduled jobs in Supabase and in apps built with Lovable do not report failures. One line at the end tells you whether they ran today.

Vercel does not retry failed cron invocations, and on Hobby the call comes some time within the hour. One line in the route reports every run.

Scheduled Functions run in UTC, for 30 seconds at most, and report no failures. One line at the end of the function does.