Buried in GLPI's Administration menu is a feature called "Automatic actions." Most administrators glance at it during installation and never return. That's a mistake -- this built-in task scheduler handles critical maintenance jobs, and misconfiguring it (or ignoring it) leads to email queues backing up, database bloat, and SLA calculations going stale.
What automatic actions are
Automatic actions are scheduled tasks that GLPI executes on a recurring basis. Think of them as GLPI's internal cron system. Each action has a name, a frequency (every 5 minutes, every hour, daily), an execution mode, and a status (active or disabled).
Navigate to Administration > Automatic actions to see the full list. A fresh GLPI installation comes with roughly 20-30 pre-configured actions.
Default actions you should understand
mailgate
Collects emails from configured mailboxes and creates tickets from them. Default frequency: every 10 minutes. If this action stops running, your email-to-ticket pipeline silently breaks and users think their requests vanished.
sla / ola
Recalculates SLA and OLA escalation timers. If this doesn't run, SLA countdowns freeze and escalation notifications never fire. Critical for any organization with contractual SLA commitments.
session
Cleans up expired user sessions from the database. Without this, the session table grows indefinitely, eventually slowing down login performance.
logs
Rotates old log entries. GLPI logs every action by every user. On an active instance with 200+ users, log tables can reach millions of rows within months if not pruned.
Actions worth enabling
Several useful actions are disabled by default:
- Auto-close resolved tickets after X days -- prevents the ticket list from accumulating resolved tickets that nobody formally closes. Set the delay in Administration > Entities > Helpdesk tab.
- Purge old tickets -- removes deleted tickets from the database after a configured retention period. Reduces database size.
- Contract alerts -- sends notifications when contracts approach their expiration date. Useful for catching renewals before they lapse.
- Certificate alerts -- notifies when SSL/TLS certificates tracked in GLPI are nearing expiry.
CLI mode vs. web mode
GLPI can execute automatic actions in two ways:
Web mode triggers actions when a user loads a page. It's the default and requires no server configuration, but it's unreliable -- if nobody uses GLPI on weekends, no actions run on weekends. Email collection stops, SLAs freeze, alerts don't fire.
CLI mode runs actions via a system cron job. This is the correct approach for production. Set up a cron entry on your Linux server:
*/5 * * * * php /var/www/glpi/front/cron.php >/dev/null 2>&1
This runs every 5 minutes. GLPI internally checks which actions are due and executes only those that have reached their scheduled interval. Once CLI mode is working, switch all actions from "GLPI" (web) mode to "CLI" mode in the automatic actions settings.
Troubleshooting common issues
Actions not running
Check the "Last run" column in the automatic actions list. If the date is hours or days old, the cron job isn't executing. Verify the cron entry, check PHP CLI permissions, and confirm the path to cron.php is correct.
Actions stacking up
If an action takes longer to complete than its frequency interval, executions can overlap. This typically happens with the mailgate action when processing a large email backlog. Increase the interval temporarily or process the backlog manually.
Email queue backing up
The "queuednotification" action sends emails from GLPI's internal queue. If emails aren't going out, check this action's status and frequency. Also verify SMTP configuration in Setup > Notifications > Email setup.
Automatic actions are GLPI's operational backbone. A well-configured action schedule means tickets flow, SLAs work, emails send, and the database stays clean -- all without anyone thinking about it. Neglecting them creates problems that surface gradually and are surprisingly hard to diagnose after the fact.