Why GLPI automatic actions should run from cron
Running GLPI automatic actions from cron is the change to make when notifications leave late, SLA escalations fire after their deadline, or mail collection misses tickets. Automatic actions are the background jobs GLPI uses for mail collection, sending queued notifications, evaluating SLAs and OLAs, and purging old logs. By default, GLPI triggers these jobs through web traffic: when a user loads a page, GLPI checks whether a due action should run. On a quiet internal instance, nobody may load a page for long stretches, so jobs wait. On a busy instance, a page load can trigger background work that slows the user's request. Teams usually need the change once tickets depend on timely email or escalation, such as service desks with contractual response times.
The fix is to set the execution mode to CLI and call bin/console from a system cron job every minute, so that due actions run on a schedule that does not depend on visitors. Before you change the mode, confirm which system account will run the job. It must be able to read the GLPI configuration and write to the files and cache directories that the web server uses, or the jobs will fail with permission errors that look like random behavior. Decide who owns the crontab entry, where its output is logged and who is alerted when the notification queue grows. Prepare a test ticket and a test mailbox so you can prove each action runs before you rely on it.
Once the change is live, verify it in GLPI instead of assuming the cron line works. Check the last-run times of mail collection, the queued notification action and the SLA actions in the automatic actions screen, and confirm that a test email reaches its recipient within the expected window. Watch for duplicate runs if a second scheduler, such as an old web-triggered setting or a second server, also executes the same actions. If you run GLPI in a container, confirm that the cron job runs inside the same environment as the application files, not on the host by mistake. Ask your implementation partner or internal team to document these checks so the next person can repeat them.
Which automatic actions to schedule and when each fits
This table compares the GLPI automatic actions most teams schedule from cron, covering what each one does, what breaks when it stops running, and how frequency trades off against load. Use it as a starting point, then confirm the mode and frequency of each action in your own GLPI administration screen before you change anything.
| Action | What it does | What breaks if it does not run | Frequency trade-off |
|---|---|---|---|
| MailCollector | Reads the configured mailboxes and turns incoming messages into tickets or followups | New email requests stop creating tickets, and replies from users do not reach existing tickets | Shorter intervals give faster ticket creation but add connections to the mail server; confirm the interval set for each collector |
| QueuedNotification | Sends notification emails that GLPI has placed in its queue | Notifications pile up in the queue and are not delivered to technicians or requesters | Frequent runs keep delivery close to real time; larger batches reduce runs but delay messages and can strain memory on big queues |
| SLA and OLA checks | Evaluates ticket deadlines and escalation rules against SLAs and OLAs | Escalations and warning notifications do not fire on time, so breaches go unnoticed | Shorter intervals catch deadlines closer to the moment they pass; longer intervals reduce database load but widen the gap before escalation |
| PurgeLogs and history purge actions | Remove old log and history entries according to configured retention | The database keeps growing, which slows queries and increases backup size | Running often keeps tables smaller but adds write load; these are usually scheduled off-peak, and the sibling purge topic covers staging |
| Other actions shown in the admin screen | Perform periodic tasks such as cleanup or data updates depending on installed plugins | Effects depend on the action; plugin actions may stop working without a visible error | Confirm each action's purpose and frequency in your own admin screen before adding it to cron |
Setting automatic actions to CLI mode and adding the cron entry
This sequence moves GLPI automatic actions from web-triggered execution to a per-minute cron job run through bin/console, so scheduled work such as mail collection, notifications and SLA checks runs on a fixed schedule that you can monitor. Each step ends with a check so you know the change took effect before you move on.
Confirm PHP CLI matches the web PHP version
The system administrator logs in to the GLPI host and runs
php -vandphp -mto compare the command-line PHP with the version and extensions the web server uses. Confirm that the CLI version meets the prerequisites for your GLPI release, which the installation docs list as PHP 8.2 or later for GLPI 11.0 and PHP 8.3 or later on the main branch. Check that the CLI loads the same extensions as the web SAPI, because a missing extension in one context causes failures that only appear in cron. Done when both versions match, meet the prerequisite, and the extension lists agree.Confirm the GLPI web user owns the files
Identify the user the web server runs as, typically a dedicated account such as www-data on Debian-based systems or apache on Red Hat-based systems, and confirm that account can read the GLPI tree and write to the files and config directories. Run the cron job as this same user so that files created by actions keep the correct ownership. Done when
bin/consoleruns without permission errors when executed as that user, for example withsudo -uusing the web user name.Set automatic actions mode to CLI in GLPI
A GLPI administrator opens Setup, then General, then the Automatic actions setting, and changes the execution mode from the web-triggered default to CLI. Save the configuration. Before you switch, record the current mode and the list of actions that are enabled, so you can restore them if needed. Done when the saved setting shows CLI and the Automatic actions list still shows the same actions as enabled.
Create the per-minute cron entry
As the GLPI web user, open the crontab with
crontab -eand add one line that runsphp bin/console glpi:maintenance:cronfrom the GLPI installation directory every minute, redirecting output to a log file you can read. Use the absolute path to the PHP binary and to the GLPI directory, because cron runs with a minimal environment. Confirm the exact console command for your release withphp bin/console listbefore you save the entry. Done whencrontab -lshows the single entry and the command appears in the output ofphp bin/console list.Confirm the cron runs in the system log
Wait at least two minutes, then check the log file you redirected output to and the cron logging on the host, for example with
grep CRON /var/log/syslogor the equivalent journal query on your distribution. Look for entries showing the job started under the web user with no errors in the redirected output. If the log is empty, check that the cron service is running and that the path to PHP is correct. Done when each minute shows a run entry and the output file contains no fatal errors.Verify each scheduled action has run
In GLPI, open Setup, then Automatic actions, and review the last run date and status for each enabled action, including mail collection, notification sending and SLA checks. Each action should show a recent run time and no error status. For an action that has not run, force it once from the command line with
php bin/console glpi:maintenance:cron --helpto confirm the available options for your release, then recheck the list. Done when every enabled action shows a current last-run time and a successful status.Prepare the rollback if actions stop
If actions stop running after the change, first check that the cron entry still exists and that the GLPI web user can run the console command. If the cause cannot be found quickly, set the automatic actions mode back to the previous web-triggered setting in GLPI, then remove or comment out the cron line so the two modes do not compete. Record the time of the change and the last successful run so the gap is visible in your monitoring. Confirm with your own environment and any vendor guidance before relying on this procedure in production.
Forcing one GLPI action from the command line
When a single automatic action misbehaves, such as a notification queue that will not drain, you can run that one action on demand from bin/console instead of waiting for the next cron cycle. Before you do, record the action's current state in the GLPI interface under Setup, Automatic actions: its last run time, its frequency, and whether it is flagged as failed or still running. Check the web server and PHP error logs for the same window and confirm the database is reachable. Then note the exact action name and the console command syntax from the documentation for your installed version, because the command and its options have changed between releases. Confirm them there rather than relying on examples from older guides.
After the run, compare the action's last run time and any counters it exposes with what you recorded beforehand. Check that the symptom has cleared, for example that queued messages are leaving or that the stuck item is no longer listed, and review the logs for new errors. If the action fails again in the same way, stop and investigate the cause instead of repeating the run. A forced run only confirms whether the action can complete; it does not fix a misconfigured mail server, a memory limit or a bad record that the action keeps hitting.
Forcing an action adds load to the database and PHP process, and that load is larger when the action touches large tables. Avoid running a heavy action such as log purging while a purge or another batch job is already in progress, because the two can compete for locks and I/O. Schedule the run for a quiet window, tell the people who rely on the helpdesk that processing may be slower, and keep a recent backup available before you start. For large installations, ask your GLPI partner or internal DBA to review the table sizes and expected impact before running anything that writes heavily.
Permissions, keys and logs to protect when running cron
Moving GLPI automatic actions to a system cron job shifts control from the web interface to the host. The considerations below cover who runs the job, who can change it, where the keys and logs live, and how the entry is kept under control. Confirm each one against your own hardening baseline before go-live.
Run cron as the file owner
The cron job should run as the same operating system user that owns the GLPI files, typically the web server user on your distribution. If cron runs as root, files written by bin/console may end up owned by root, and the web server may then fail to read or update them. Check ownership of the GLPI tree after the first few runs, and confirm the expected user with your platform team and your distribution's packaging.
Protect the config directory and keys
The config directory holds the database connection and the glpi.key and glpicrypt.key files, which GLPI uses for encryption. Anyone who can read them can decrypt stored secrets, so the directory should not be readable by other local users or served by the web server. Keep the keys in your backup scope with restricted access, and confirm the permission model with your hardening baseline.
Restrict who changes action modes
Switching an automatic action to CLI mode in the GLPI interface is a configuration change that alters how mail and notifications are processed. Limit the administrator profiles that can edit automatic actions, and review those changes in your normal change process. Ask GLPI administrators to record who changed the mode and why.
Monitor cron and application logs
A cron job that fails silently leaves mail queued and SLAs unchecked. Capture the output of the scheduled command, and watch the GLPI log directory and the system cron log for errors from bin/console. Alert on repeated failures rather than single errors, and confirm the log locations and retention with your logging team.
Keep bin/console off the web
bin/console is a command line tool and should never be reachable through the web server. Confirm that the document root points to the public directory, as the installation docs require, so the console and other files outside that directory are not served. Test this from outside your network after each web server change.
Manage the cron entry as code
The cron line is part of the server's configuration, so it should be defined in your configuration management tool rather than edited by hand. A managed entry is reviewed, versioned and restored after a rebuild or upgrade. Record the user, schedule and command path, and check the entry again after each GLPI update, since file paths can change.
Questions teams ask before running GLPI cron jobs
How long does it take to switch GLPI automatic actions to cron?
The switch itself is a short change, but total time depends on the server layout, the number of actions you schedule and how much testing you need before trusting the schedule. The main drivers are whether GLPI runs on a single host or a cluster, whether mail collection and notification queues need to be verified against your real mail servers, and whether a maintenance window is required. Ask any partner for a written scope that lists the environments covered and the verification steps, since those determine the effort. DeployOpen agrees timelines in writing as part of a fixed-scope engagement before work starts.
Can our internal team set up GLPI cron jobs without a partner?
Yes, in most single-server installations an administrator who can edit the crontab and run commands as the web server user can complete the change. The work is small, but it requires a clear understanding of which automatic actions to move, how to confirm each one runs, and how to recover when a run fails. Teams that run GLPI in several environments, or that lack a Linux administrator familiar with PHP and cron, often choose to have a partner document the configuration and test it. Either way, keep the configuration in version control and record who owns the schedule.
What access and information do we need to provide for cron setup?
The work needs a few concrete inputs before it starts:
- Shell access to the GLPI server with rights to edit the crontab of the user that runs PHP, plus read access to the GLPI installation directory
- Working SMTP and IMAP settings, including test mailboxes, so mail collection and notifications can be checked
- A maintenance window for the change, and a named contact who can confirm that tickets and notifications behave as expected afterward
- Current backups of the database and files, consistent with your GLPI update and recovery procedures
Confirm your own change approval rules, because some organizations require a formal change record even for a scheduling change.
What does it cost to have DeployOpen set up GLPI cron jobs?
DeployOpen does not publish a price list. Cost follows from the written scope, which typically covers the number of GLPI instances, the automatic actions to schedule, the mail and notification checks, documentation and any handover training. One-time work is the setup and verification. Recurring cost appears only if you add a retainer for ongoing support, upgrades or monitoring. Ask for a quote that separates these items and states the environments, exclusions and acceptance tests. For context on GLPI's own licensing, the GLPI Network subscriptions page lists self-hosted subscription tiers, but those are separate from implementation work.
What should we check when GLPI automatic actions stop running?
Start by confirming that the cron entry still exists and that it runs as the correct system user, since a changed user or PHP path is a frequent cause of silent failure. Next, run the suspected action from the command line and read its output, which shows whether the failure is in the action or the environment. Check the GLPI logs and the status of the notification queue, and confirm that the database and mail servers are reachable. If a deployment or update recently occurred, check whether plugins were suspended, since GLPI 11 suspends plugins after a new version is detected and they must be reactivated after major updates.
Does a GLPI cron job replace monitoring?
No. A cron entry runs actions on a schedule, but it does not tell you whether those actions succeeded, how long they took or whether the queue is growing. You still need an alert when the scheduled job stops, a check on the age of the oldest queued notification and a review of error output. Many teams add a simple heartbeat or log-based check alongside the crontab, then route alerts to the same team that handles GLPI incidents. Confirm your monitoring tool and alert routing during setup so that a silent failure does not go unnoticed.
Which automatic actions should we schedule with cron?
Mail collection, notification sending and SLA checks are the usual candidates because they depend on regular execution to keep tickets and alerts current. Other actions, such as log purging, should be scheduled deliberately because they change data and affect storage. Review each action's frequency and effect in your own environment before enabling it, and test with a copy of your data. Your team should decide which actions it needs, and the setup should document the reason for each entry.
Official GLPI sources for automatic actions and installation
The GLPI installation documentation is the authoritative next read for the exact console commands, PHP extensions and database versions that a cron-driven setup depends on. Start with its prerequisites page, because the version floors it lists for GLPI 11.0 differ from those in the project README on the main branch. Before you change the crontab, confirm which GLPI line you run, then check the matching requirements for your PHP build and whether your database engine is MySQL or MariaDB, since those are the only two engines the documentation says are supported.
The GLPI installation documentation also explains the web server layout that the cron job must respect: the document root should point to GLPI's public directory, not the installation root. Keep that in mind when you run bin/console as a scheduled user, because the file ownership and PHP binary used by cron should match the ones the web server uses, or the action will write logs and sessions with the wrong permissions.
For release news and version history, the GLPI project site points to the current maintained line and the official release notes. Read the notes for the version you plan to run before changing scheduling, because automatic action behavior and plugin handling can change between major releases. Confirm details such as the exact cron entry syntax and any action names against the documentation for your installed version rather than relying on examples written for an older release.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For automatic actions, that means agreeing in writing which actions run from cron, how the host is configured, and how each run is verified before the work begins.
How we scope
- Written scope lists which GLPI automatic actions move to CLI mode and which stay on the web trigger.
- Scope records the hosts, PHP user, cron ownership and log locations that the cron job will use.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We configure the per-minute cron entry, run the first cycles by hand and confirm each action completes.
- We check the mail collector, notification queue and SLA actions against your mail flow and ticket volumes.
- We test forcing a single action from the command line in a non-production copy before production use.
How we hand over
- Handover includes the cron entry, the action schedule, and a record of every action changed from the web.
- Runbooks explain how to read the automatic actions page, interpret failed runs and force one action safely.
- Your team receives the configuration as files and notes so the setup can be reviewed or rebuilt.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for GLPI after go-live.
- Support reviews automatic action health after each GLPI update, since plugin and schema changes can affect them.
- Ask any provider to confirm which GLPI version and PHP version the cron setup was verified against.
