The first month of a GLPI deployment, things mostly work. The mistakes made then — like missing a category or picking the wrong cron interval — get caught early because everyone's paying attention. The real gotchas are the silent ones that surface 6 – 12 months later, when the project is "done" and nobody's watching the operational details. Eight problems that show up in roughly that order, with what to look for and how to fix.
1. The cron job that quietly stopped running
GLPI relies on a system cron entry (or web-based cron) to run scheduled actions: SLA escalations, contract expiry alerts, automatic notifications, recurring ticket creation, KB index rebuilds, mail receivers. If cron stops, none of these fire. There's no UI banner that says "your cron hasn't run in 4 days".
Symptoms: SLA timeouts that never escalate; contract expiry notifications that don't arrive 90 days before; recurring tickets that don't create on schedule.
Check: Setup → General → Automatic actions. Each row has "Last run" — anything older than its frequency is broken. Confirm cron at OS level:
# Linux: verify www-data cron entry exists
sudo crontab -u www-data -l
# Should contain: */1 * * * * /usr/bin/php /var/www/glpi/front/cron.php
# Verify it's actually firing
sudo grep cron.php /var/log/syslog | tail -102. Plugin breaks on minor GLPI upgrade
GLPI ships minor versions every 4 – 6 weeks. Most plugins (Formcreator, FlyveMobile, custom plugins) declare a compatibility range. When you upgrade GLPI by one point release, half the plugins may stop loading.
Symptoms: blank pages on Formcreator forms, "Plugin not loaded" warnings in Setup → Plugins, missing menu items.
Mitigation: always check plugin compatibility BEFORE GLPI upgrade. The compatibility matrix is in each plugin's GitHub repo. If a plugin you depend on doesn't support the new version, defer the GLPI upgrade.
3. LDAP sync drifts (users vanish)
GLPI syncs users from Active Directory or another LDAP source. The sync runs as a cron action; it adds new users, marks departed users as "deleted" (not actually removed). Drift happens when the LDAP filter is too narrow — users who change their group or move OUs disappear from GLPI.
Symptoms: technicians complain "I can't assign tickets to Karol any more, his account is gone". HR confirms Karol still works there.
Check: Setup → Authentication → LDAP directories. Test the bind, test the filter. The filter should match every active employee, not just current members of a specific group.
4. Profile permissions tangle
You add custom fields, custom item types, new categories. Each one has a permission flag in profiles. Months later, a junior technician can't see a ticket category because their profile predates that category and was never updated.
Symptoms: "I can't see this ticket type", "Only the IT manager has access to security incidents", arbitrary visibility holes.
Mitigation: when you add a feature, immediately review which profiles need access. Document the profile-to-feature matrix in your ops runbook.
5. Contract expiry alerts misconfigured
You set up Contract objects with end dates and a 90-day pre-expiry alert. Six months later, a contract expires without a single email. Investigation: the alert recipient was set to a person who left the company.
Symptoms: contract auto-renews at the original (worse) terms because nobody got the warning to renegotiate.
Check: every alert recipient should be a group (e.g. "Procurement"), not a specific user. Audit recipients quarterly.
6. Email-to-ticket loop / autoresponder storm
You configure GLPI to ingest emails into tickets. Someone sends a message to support@; GLPI creates a ticket; GLPI sends an autoresponder; the original sender's mailbox sends an out-of-office reply; GLPI ingests that as a follow-up; another autoresponder; loop.
Symptoms: 50 tickets created in a single hour from one email thread. Helpdesk inbox flooded.
Mitigation: in Setup → Receivers, configure subject filters to reject auto-reply and bounce headers (X-Auto-Response-Suppress, Auto-Submitted). And add a circuit-breaker: max 5 emails per sender per hour.
7. Slow database (no maintenance)
GLPI's MariaDB database accumulates: ticket history, audit logs, computer inventory snapshots, software inventory entries. After 12 months on a 200-asset deployment, the glpi_logs table can hit several million rows. Queries slow down. UI feels laggy.
Symptoms: pages that took 200 ms now take 2 seconds. Dashboards take 10+ seconds to render.
Maintenance: run GLPI's purge automatic actions (Setup → General → Automatic actions → purgelogs). Schedule MariaDB OPTIMIZE TABLE quarterly on the largest tables. Consider archiving closed tickets older than 2 years to a separate database if regulations allow.
8. Backup that wasn't tested
You set up nightly mysqldump + file backup of the GLPI installation directory. Cron runs, files appear on the backup server. Twelve months later you actually need to restore — and discover the dumps are corrupted, the file backup excludes plugins/, or the backup SSH key was rotated and nothing has actually been backing up for 4 months.
Symptoms: discovered only on disaster, when too late.
Test: every quarter, restore the latest backup to a staging VM and verify GLPI boots and the data looks right. This is the single highest-leverage operational habit and the most commonly skipped one.
The pattern
None of these are bugs in GLPI. They're operational hygiene problems for any self-hosted system — and they bite because months 6 – 12 are when "done" starts meaning "unmonitored". A quarterly checklist that touches all eight is the difference between a deployment still trusted in year 3 and one quietly rotting.