Setting up GLPI cron on Linux

GLPI ships with a pseudo-cron that runs its Automatic Actions (notifications, CI updates, data purges, inventory processing) on every page view. It works fine on a busy instance, but it has one obvious failure mode: if nobody loads a page, nothing runs. Emails sit in the queue, escalations don't fire, and scheduled reports never send.

The fix is a real cron job. Here's how to set it up cleanly on modern Linux.

1. Pick the right PHP CLI

The old PHP 5 binary (/usr/bin/php5) is long gone. Modern distros ship PHP 8.x, and GLPI 10+ requires at least PHP 7.4. Find the CLI binary:

which php
# or for a specific version:
ls /usr/bin/php*

On Debian/Ubuntu with multiple PHP versions installed, target the specific one GLPI uses (often /usr/bin/php8.2) rather than the /usr/bin/php alternative, which can flip under you after upgrades.

2. Confirm the GLPI install path

The cron entrypoint is front/cron.php inside your GLPI directory. Common locations:

• /var/www/glpi/front/cron.php — typical manual install
• /var/www/html/glpi/front/cron.php — Apache default on RHEL/CentOS
• /usr/share/glpi/front/cron.php — Debian package install

Adjust the examples below to match your setup.

3. Add the cron job — run as the web user

Don't run GLPI's cron as root. Run it as the same user that serves the web requests (www-data on Debian/Ubuntu, apache on RHEL/CentOS, nginx if PHP-FPM runs under that user). Otherwise cron-created files will have wrong ownership and the web server won't be able to write over them.

Edit the crontab for that user:

sudo crontab -u www-data -e

Add the job:

*/2 * * * * /usr/bin/php8.2 /var/www/glpi/front/cron.php >/dev/null 2>&1

Every 2 minutes is a good default — it's the standard GLPI recommendation and keeps notifications timely without hammering the database. Save and exit (:wq in vim, Ctrl+X then Y in nano).

4. Switch Automatic Actions to CLI mode

By default, Automatic Actions run in GLPI mode (via pseudo-cron). Flip them to CLI so the external cron handles them:

1. Go to Setup → Automatic actions
2. Open each action you want cron-driven (at minimum: mailgate, queuednotification, telemetry, notification)
3. Change Run mode from GLPI to CLI
4. Save

Actions left in GLPI mode will keep running on page views — that's fine if you want a hybrid setup, but the whole point of this guide is to make critical actions independent of user traffic.

5. Verify it's working

Run the cron script manually first to catch permission or path errors:

sudo -u www-data /usr/bin/php8.2 /var/www/glpi/front/cron.php

Then check GLPI's Automatic actions list — the "Last execution" column should update within a couple of minutes of your cron schedule. If it doesn't:

• Check cron is running: systemctl status cron (Debian/Ubuntu) or systemctl status crond (RHEL)
• Check the user's crontab was saved: sudo crontab -u www-data -l
• Check for PHP errors in /var/log/syslog or via journalctl -u cron
• Confirm the PHP CLI can read GLPI's config: the web user must own or have read access to files/_log/ and the config directory

systemd timer alternative

On modern systems you can skip cron entirely and use a systemd timer. Create /etc/systemd/system/glpi-cron.service:

[Unit]
Description=GLPI cron

[Service]
Type=oneshot
User=www-data
ExecStart=/usr/bin/php8.2 /var/www/glpi/front/cron.php

And /etc/systemd/system/glpi-cron.timer:

[Unit]
Description=Run GLPI cron every 2 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=2min

[Install]
WantedBy=timers.target

Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable --now glpi-cron.timer

Systemd gives you proper logging via journalctl -u glpi-cron.service and retries on failure, which vanilla cron doesn't. Either approach is fine — pick whichever matches your ops stack.