GLPI opens preventive maintenance tickets on its own: printer cleaning, backup testing, service password changes, access reviews. We tested recurrent tickets in GLPI 11 and they work, but three details make preventive maintenance disappear or come out wrong without any warning. A monthly recurrence that starts on the 31st ends up falling on the 3rd. A preliminary creation longer than the periodicity means GLPI never creates anything. And a template without fields generates a blank ticket.
What recurrent tickets are for
Every routine that today depends on someone remembering:
- Preventive maintenance of printers, UPS units and server room air conditioning.
- Backup restore testing (a backup that has never been restored is not a backup; see backup and disaster recovery in GLPI).
- Quarterly review of access rights and inactive accounts.
- Renewal of certificates, licenses and domains.
- Month-opening and month-closing checklists.
The ticket is born on the right day, with category, group and description ready, enters the queue and counts toward the SLA like any other.
How to configure it
1. Create the ticket template
The recurrent ticket has no title or description of its own: it copies everything from a Ticket template. In the template's predefined fields, fill in at least:
- Title and description (with the task checklist);
- Category and type (usually Request);
- Assigned group, so the ticket is not born without an owner;
- Urgency or priority.
2. Create the recurrent ticket
In Assistance > Recurrent tickets:
| Field | What to enter |
|---|---|
| Active | Yes |
| Ticket template | The template from step 1 |
| Start date | The first occurrence (day and time) |
| End date | Optional; after it, GLPI stops creating tickets |
| Periodicity | From 1 hour to 10 years (hours, days, months or years) |
| Preliminary creation | How long before the occurrence the ticket should be opened (up to 2 weeks) |
| Calendar | Optional; pushes creation to the next working day and time |
In the items tab, link the assets (the printer, the server) so the ticket is born already linked to them.
3. Check the automatic action
Tickets are created by the RecurrentItems automatic action, which runs every hour. In practice, the ticket may appear up to an hour after the scheduled time. If the exact time matters, use a preliminary creation of at least 1 hour. And GLPI's cron must be running (see step 6 of how to install GLPI 11).
The test: where recurrence goes wrong
We used GLPI 11's own calculation to see the next dates in cases that often cause problems, and we created real tickets in our test entity (fictitious data, deleted afterwards).
| Case | Next dates GLPI calculated | What happens |
|---|---|---|
| Monthly starting Jan 31 | Jan 31, Mar 3, Apr 3, May 3 | Slips to the 3rd and stays there forever |
| Monthly starting Jan 28 | Jan 28, Feb 28, Mar 28, Apr 28 | Correct |
| Weekly starting on a Saturday, without calendar | Oct 10, Oct 17, Oct 24 (Saturdays) | Creates on the weekend |
| Weekly starting on a Saturday, with calendar | Oct 12, Oct 19, Oct 26 (Mondays) | Moves to the next working day |
| Daily with a 2-day preliminary creation | none (next date empty) | Never creates anything |
| Template with title and description | ticket created with both | Correct |
| Template without any field | ticket created with empty title and description | A blank ticket enters the queue |
The three pitfalls
1. The 29th, 30th or 31st in a monthly recurrence
With a periodicity in months, GLPI adds "1 month" to the date. February has no 31st, so Jan 31 + 1 month becomes Mar 3, and from then on the recurrence stays on the 3rd. The "last day of the month" preventive task becomes the "3rd of the month" one.
Solution: start monthly recurrences between the 1st and the 28th. If it has to be at the end of the month, use the 28th and a preliminary creation.
2. Preliminary creation longer than the periodicity
In a daily recurrent ticket with a 2-day preliminary creation, GLPI considers the configuration invalid and leaves the next date empty. On screen, the recurrent ticket shows as active; in practice, it creates nothing.
Solution: the preliminary creation must be shorter than the periodicity. After saving, check that the next creation date has been filled in.
3. Template without fields
If the template has no title or description, GLPI creates the ticket anyway, blank. Nobody knows what to do with it, and it sits idle in the queue.
Solution: title, description, category and group in the template, always. And open the recurrent ticket's history: each creation leaves a message, including when it fails.
Best practices
- One recurrent ticket per routine, with the routine and the periodicity in the name ("Printer preventive maintenance - monthly").
- Checklist in the description, with what to do and how to record the result.
- Calendar with holidays so tickets are not created on non-working days: see how to generate and link holiday calendars.
- Proportional resolution SLA: a monthly preventive task does not need the SLA of an incident.
- Quarterly review of the recurrent ticket list: replaced equipment, a routine that changed, an expired end date.
- Changes can be recurrent too (Assistance > Recurrent changes), for planned maintenance windows.
NexTool test on October 4, 2026, on our support team's GLPI 11.0.7, in a test entity with fictitious data. The next dates were calculated by GLPI's own function; the test templates, recurrent tickets and tickets were deleted at the end.
Comments
Comments on this post come from GitHub (giscus). When you load them, your browser connects to GitHub, which receives your IP address and may set its own cookies.
To load them automatically, enable functional cookies