Every service desk tool has a "close tickets automatically after N days" feature, and GLPI is no exception. Configuring it takes five minutes. The harder question is whether you should — and for most teams the honest answer is "not for the reason you think you need it." This guide shows both: how to set it up in modern GLPI, and when the auto-close shortcut actually makes things worse.
How GLPI closes tickets automatically
GLPI's ticket lifecycle goes New → Processing → Solved → Closed. Agents move tickets to Solved when the work is done; the Closed step exists as a confirmation that the user agreed with the resolution. Auto-close skips that confirmation by transitioning Solved tickets to Closed after a configured interval.
The mechanism has two moving parts:
- An Automatic Action (
closeticket) that runs on a schedule and finds solved tickets older than the threshold - A per-entity setting that defines the threshold — how many days a ticket can sit in Solved before auto-close picks it up
1. Make sure Automatic Actions run
Before the close job can fire, GLPI's Automatic Actions have to be running. Out of the box they run via pseudo-cron (on page views), which is unreliable for background work. If you haven't switched to a real cron yet, follow our GLPI cron on Linux guide first. Without it, closeticket will only run when someone happens to be browsing GLPI — which defeats the point.
2. Confirm the closeticket action is scheduled
Go to Setup → Automatic actions and find closeticket. Check:
- Status: Scheduled
- Run frequency: every 1–2 hours is fine. This job is cheap — it's a SQL query, not heavy lifting
- Run period: set this to business hours if you don't want closure notifications landing in inboxes at 3am
- Run mode: CLI if you've set up real cron, otherwise leave as GLPI
3. Configure the per-entity threshold
The threshold lives on the entity, not global settings. Go to Administration → Entities, pick the entity you're configuring (usually Root entity if you've not sub-divided), and open the Assistance tab.
Set Automatic closing of solved tickets after to the number of days you want. Common values:
0days — close immediately on the next closeticket run (aggressive; users get no window to reopen)3days — a common "best practice" middle ground7days — gives users a full work week to push back before closure
Save. Sub-entities inherit unless you override at their level.
4. Test it
Put a test ticket into Solved state, then run the closeticket action manually from Setup → Automatic actions → closeticket → Execute. The ticket should flip to Closed if the threshold is 0 (or if you backdate the Solved timestamp for longer thresholds).
Check files/_log/cron.log if nothing happens — the most common cause is that Automatic Actions aren't actually running in the mode you set.
Notifications get noisy — fix that now
By default, GLPI sends both a "ticket solved" and a "ticket closed" notification. Once auto-close is on, that's two emails for every ticket, seconds or minutes apart. Users will complain.
Under Setup → Notifications → Notifications, disable one of them (usually "Ticket closed" — the "solved" notification carries the satisfaction survey link, if you use it). Or create a business rule that suppresses the closed notification when the transition was triggered by auto-close rather than a human.
Why we recommend against auto-close as a default
Auto-close exists because queues get cluttered with tickets users forgot to reply to. That's a real problem. But auto-close treats the symptom rather than the cause, and it breaks one of the few useful feedback loops in an ITSM process.
Every ITIL-family framework — incident management, request fulfilment, problem management — includes a verification step before closure. Not because ITIL says so, but because that step is where you find out that:
- Your "fix" didn't actually fix the user's problem
- The user has a follow-up question that's actually a new ticket
- The symptom recurred two hours after the agent marked it solved
- The resolution worked but broke something else
Auto-close hides all of that. Tickets that should have come back as reopens instead get filed as success stories, and your resolution metrics stop meaning anything.
The pattern we actually recommend
Use auto-close as a cleanup mechanism, not a closure mechanism:
- When an agent solves a ticket, GLPI sends the solved notification with a "Was this fixed?" satisfaction survey link and/or a reply-to-reopen note
- If the user replies or clicks "No" within, say, 7 days → ticket reopens (GLPI does this automatically on reply)
- If the user doesn't respond at all after 7 days → auto-close picks it up as a cleanup pass
The point isn't to close tickets faster. It's to give users a real window to push back, default to closure only when they don't. Set the threshold long enough (3–7 days, not 0) that silence plausibly means consent.
And if you're serious about resolution quality, add the satisfaction survey (GLPI has this built in via the Satisfaction feature at Administration → Entities → Assistance tab). Surveys are short, non-intrusive, and give you actual data on whether the fix landed — which auto-close alone cannot.