Nextcloud Background Jobs: How to Set Up External Cron and Monitor It

Nextcloud runs background tasks only when someone opens it in a browser. If you've dealt with WordPress and WP-Cron, this will sound familiar — it's the same problem. For a cron job to fire, a user has to visit a page, and that visit triggers the script. No visit, no cron.

Background tasks like clearing the trash, sending notifications, syncing external storage, and pruning old file versions all need to run without anyone doing it manually. On a small instance where two or three people check files once a day, these jobs pile up and don't run on time. We'll get into why this happens and how to fix it below.

What runs in the background

Nextcloud queues more background work than most admins expect. The core alone handles database cleanups, garbage collection of temporary files, trash bin expiration, old file version pruning, and update checks. Apps add to the pile: Activity sends notification emails, External Storage scans for changed files via filescan(), Calendar and Contacts process subscription syncs, and Talk cleans up expired conversations.

A typical Nextcloud instance with 10+ apps might have dozens of registered background jobs. In AJAX mode, at one job per page load, the queue backs up fast. Webcron mode improves this to one job per external call, but even at 5-minute intervals that caps out at 288 jobs per day. Fine for a personal install. Not enough for a team instance with 20 users and active file sharing.

AJAX, Webcron, Cron: three modes, one recommendation

Nextcloud offers three ways to run background jobs. The admin panel under Administration Settings > Basic settings shows all three. Here's what each actually does.

AJAX (default): piggybacks on user page loads. Every time someone opens Nextcloud in a browser, one background job fires. No visitors, no jobs. Nextcloud's own docs call this "the least reliable" and recommend it only for single-user setups.

Webcron: an external service calls cron.php over HTTP on a schedule. Better than AJAX because it doesn't depend on visitors. But it still runs through the web server, which means resource limits apply. Only one job per call, and the web server's max_execution_time can cut long-running tasks short.

Cron (recommended): the operating system's cron daemon runs cron.php via CLI. No web server involved, no resource caps from Apache or Nginx. Processes as many jobs as needed per run. The standard cron setup:

crontab -u www-data -e

Then add:

*/5 * * * * php -f /var/www/nextcloud/cron.php

Replace www-data with your web server user and adjust the path to your Nextcloud installation. Once cron.php runs from CLI, Nextcloud auto-detects the change and switches to Cron mode in the admin panel.

When you can't use system cron

Cron mode needs SSH access to the server and the ability to edit crontab. That rules out a lot of Nextcloud deployments.

Managed hosting where the provider pre-installs Nextcloud but doesn't give you shell access. Docker setups where cron isn't running inside the container. I've debugged this one more than once: the official Nextcloud Docker image doesn't include cron, and people assume it does. NAS devices like Synology or QNAP where Nextcloud runs as a package but system cron isn't exposed to the app. Shared hosting where you installed Nextcloud manually but can't SSH in.

For all of these, Webcron is the fallback. And Webcron is just an HTTP GET request to a URL on a schedule. Which is exactly what an external cron service does.

Your Webcron URL:

https://your-nextcloud-domain.com/cron.php

If Nextcloud sits in a subdirectory:

https://your-domain.com/nextcloud/cron.php

No authentication needed for this endpoint. Point any external service at it with a 5-minute interval (*/5 * * * *) and background jobs start processing on schedule.

Why manual cron setup is harder than it looks

Setting up cron manually sounds simple: add a line to the crontab, done. In practice, most Nextcloud users aren't server admins. They don't know cron syntax, they've never opened a terminal, and "edit the crontab" isn't something they can do without a guide open on the second monitor. Even for people who do get it running, problems tend to follow.

Three issues come up in Nextcloud forums over and over:

APCu not enabled for CLI. Most Nextcloud installs use APCu for memory caching. When cron.php runs from the command line, it needs apc.enable_cli=1 in the PHP config. Without it, cron fires but silently crashes on cache errors. Nothing in the admin panel tells you this is happening. Fix: add it to /etc/php/8.x/cli/conf.d/20-apcu.ini or pass it inline:

*/5 * * * * php -d apc.enable_cli=1 -f /var/www/nextcloud/cron.php

Wrong PHP version. After a PHP upgrade, the php command in crontab might still point to the old version. Nextcloud 28+ needs PHP 8.1 at minimum. If cron runs with 7.4, it fails without any visible error. Use the full path: /usr/bin/php8.2 instead of just php.

Wrong user. Cron.php has to run as the web server user (www-data or nginx). Running it as root creates files with root permissions in the data directory, and Nextcloud can't read them afterward. Use crontab -u www-data -e to make sure you're editing the right user's crontab.

All of this is why Webcron exists as an option. An external cron service takes the terminal, the syntax, and the PHP configuration out of the equation. You give it a URL and an interval, and it handles the rest. No SSH, no crontab, no "which PHP binary am I even running."

Monitor Nextcloud cron with WatchCron Cloud Cron

Nextcloud shows the last background job timestamp in the admin panel. Useful if you check it. Most admins don't look at that page until something is already broken.

Cloud Cron replaces the Webcron approach with monitoring on top. Enter your cron.php URL, set the interval to every 5 minutes, and Cloud Cron handles the trigger. If the endpoint returns an error, times out, or becomes unreachable, you get an alert through Slack, Telegram, email, or any of 20+ channels.

For instances that already have system cron running, heartbeat monitoring adds a safety net without changing the trigger method. Append a ping after cron.php:

*/5 * * * * sudo -u www-data php -f /var/www/nextcloud/cron.php && curl -fsS https://ping.watchcron.com/your-monitor-id > /dev/null

If cron.php exits with an error, the ping doesn't fire. If the server goes offline, same thing. Either way you find out in minutes, not when a user reports that their trash hasn't been emptied in a month.

Nextcloud's own docs point users toward easyCron for Webcron. Cloud Cron does the same job, with the difference that it tells you when things stop working. One thing it won't catch: if cron.php runs fine but an app inside Nextcloud silently fails during the job. For that you still need to check the Nextcloud log. WooCommerce, Magento, and PrestaShop stores use the same pattern for their own cron dependencies.