The best way to forget the quarterly access review is to rely on someone remembering it. The best way to never forget it is to let the system create a ticket — with a technician assigned, a category set, a checklist attached — exactly on the day it's due. The native Recurring tickets feature in GLPI does this without any plugin.
What a recurring ticket is
Under Tools → Recurring tickets you configure a schedule that the GLPI cron evaluates daily. The schedule has three pieces:
- Ticket template — defines the content: title, description, category, urgency/impact, target group, location, custom fields. The template is created beforehand under Tools → Ticket templates.
- Time plan — when and how often the ticket should be created: first-occurrence date, periodicity (every day, every X days, weeks, months, years, or a custom cron-like expression), creation time.
- Calendar — an optional working-day calendar. If set, the ticket is created only on a working day. A quarterly review that lands on 1 January is pushed to 2 January.
Step-by-step configuration
- Under Tools → Ticket templates create a template, e.g. "Monthly backup verification — production servers". Fill in the title, description (with the checklist), category, target group, and urgency.
- Under Tools → Recurring tickets → Add name the schedule (e.g. "Backup verification — monthly").
- Pick the template from step 1.
- Set Begin date (when the schedule becomes active) and End date (optional, for time-bounded schedules).
- Under Periodicity pick the interval — for a monthly review choose "1 month" and set Creation time to "08:00".
- Optionally attach a calendar (if it shouldn't fire on weekends or holidays).
The schedule becomes live immediately — at the next cron run (hourly by default), GLPI checks whether it's time to create a ticket.
Use cases with concrete intervals
- Daily (every morning at 06:00): backup log review for the previous night. The created ticket has a checklist: "Check the Veeam dashboard, verify all jobs succeeded, attach a screenshot".
- Weekly (Monday at 08:00): weekly status meeting prep — generate a report of unresolved P1/P2 incidents, attach to ticket, team lead reviews.
- Monthly (1st of the month): disk-usage review, monthly uptime report, helpdesk billing summary.
- Quarterly: access review (who has what rights in the ERP, who shouldn't), patch-Tuesday retrospective, security awareness email.
- Half-yearly: SSL certificate expiry sweep (even if monitoring covers it, the ticket is the explicit record).
- Yearly: licence renewal alerts (M365, antivirus, support contracts), penetration test, disaster recovery drill.
Skip-on-holiday and working hours
GLPI has the concept of a Calendar in Setup → Dropdowns → Calendars. There you define working days, working hours, and holidays. On a recurring ticket, if the linked calendar marks a day as a holiday, the ticket isn't created — it's pushed to the next working day.
This matters for tasks like "monthly helpdesk billing on the 1st" — if the 1st falls on a Sunday, pushing to Monday is the correct behaviour. For tasks like "daily backup verification" it isn't — backups run on weekends too and need checking on Saturday. In that case don't attach a calendar.
Common mistakes and tips
A few patterns repeat in early implementations:
- Description that's too thin — "Check the backups" is bad guidance. For a ticket to work even when a stand-in technician handles it, the description has to contain a concrete checklist and links to documentation.
- No assigned group — if the template has no Assigned group, the ticket lands in the "Unassigned" bucket and gets lost there. Always set a target group, even one that rotates on a member.
- Not respecting holidays — for reviews and checks tied to working days, always attach a calendar.
- No progress monitoring — build a saved search "Recurring tickets older than 2× their expected resolution time" and open it weekly. Without it, an abandoned recurring ticket behaves like quiet technical debt.
Reporting and audit traceability
Every recurring-ticket-created ticket has the Source field set to Recurring ticket, so filters and reports can easily separate them from ad-hoc requests. For audits (ISO 27001, NIS2) this is enormously valuable — instead of "we run a monthly review", you have a concrete trail of created tickets, who handled them, when they closed, and what comments they contained.
Recurring tickets aren't just a convenience — they're documented discipline. Without them, routine checks depend on technician memory. With them, they're part of a process that doesn't slip when the team is under pressure or out of office.