How GLPI recurrent tickets keep routine work on schedule
Routine work such as backup verification, patch reviews and monthly access reviews gets missed when it lives in calendars or in someone's memory. GLPI can generate tickets or changes from a template on a set periodicity, so each occurrence appears in the queue with the same fields, category and assignment every time. Confirm the exact menu names, periodicity options and the GLPI version you run (the current releases are 11.x and 12.x), because the recurrence settings and their location in the interface have changed between versions and should be checked in your own instance before you design the workflow.
Use a single ticket when the work is a one-off request or incident with its own requester and resolution. Use a recurrent ticket when the same operational task must happen again on a predictable cycle, such as a weekly backup restore test, and the outcome of each run matters for reporting. Use a recurrent change when each cycle needs the approval and planning steps of change management, for example a monthly firewall rule review that must be recorded before it is applied. A problem record fits a different need: it groups repeated incidents to find a root cause, and a recurring ticket will not diagnose why an incident keeps happening. GLPI is an ITSM platform for tickets, assets and CMDB, so the recurring task should point to the affected asset or configuration item, which lets the team trace each occurrence back to the system it covers.
Recurrence options and when each fits
This table compares recurrent tickets and recurrent changes against the periodicity options and routine work types they usually serve. Exact option labels, calendar behavior and approval handling vary by GLPI version, so confirm each one in your own instance before you build templates. The main takeaway is that the object you choose (ticket or change) decides which SLA clock and approval flow the routine work follows.
| Option or work type | Recurrent ticket | Recurrent change |
|---|---|---|
| Backup verification (daily or weekly) | Fits checks with a clear pass or fail result and an SLA clock the team must meet | Usually unnecessary unless the check itself alters production settings |
| Monthly access or licence review | Fits reviews that close with a result and need an owner and due date | Fits only when the review produces a planned change needing approval |
| Scheduled maintenance window | Weak fit, since the work needs approval and scheduling control | Fits best, because the change carries approval steps and planned timing |
| Daily, weekly or monthly periodicity | Available as periodicity choices; confirm labels in your version | Available as periodicity choices; confirm labels in your version |
| Custom interval | Confirm whether your version accepts an interval that is not a standard period | Confirm whether your version accepts an interval that is not a standard period |
| Calendar use | Check which calendar drives due dates so weekends and holidays do not distort targets | Check which calendar governs the planned window and any blackout periods |
| SLA clock impact | Ticket SLA applies to each generated occurrence, and pending status pauses the clock | Change timing is governed by planned dates rather than a ticket SLA clock |
| Approval flow | Approval only applies if you add validation steps to the generated ticket | Approval is built into the change lifecycle and applies to every occurrence |
Setting up a recurrent ticket from a template
This sequence produces one recurring ticket that GLPI creates on schedule from a template, with the category, entity, assignee group and SLA already set. Each step ends with a check, so you can confirm the schedule works before routine work depends on it.
Confirm the GLPI version and scheduler
Check the installed GLPI version on the administration information page and note it in your change record, because menu names and automatic action options can differ between the 10, 11 and 12 release lines. Then confirm that the system cron job that drives GLPI's automatic actions runs on the schedule described in the installation documentation for that version. Done when the Automatic actions page shows a recent last-run time for the cron-driven actions and you can name the server that runs them.
Build the ticket template
As a super-administrator, open the ticket template configuration under setup and create a template for the routine work, such as a monthly backup verification. Set the title, description and request type, then the category, entity, assigned group and SLA fields the team needs, and mark any field that must always be filled as mandatory. Done when you create a test ticket from the template manually, the fields arrive populated as designed, and you delete the test ticket afterward.
Create the recurrence definition
Open the recurrent ticket configuration under the ticket menu and create a new definition that points to the template. Set the periodicity, the first creation date and the calendar that decides on which days tickets may be created, such as a business-day calendar for the service desk. Done when the definition saves and the next creation date it displays matches the date your team expects, which you should confirm against the calendar you selected.
Check the SLA attached to the template
Before the first run, confirm that the SLA and, where used, the OLA on the template are the ones your service level agreement specifies for this work. Review how the SLA calendar differs from the recurrence calendar, since the recurrence calendar controls creation while the SLA calendar controls the time targets. Done when the template preview shows the expected SLA and you have written down who owns the SLA configuration so that later changes are traced.
Run the automatic action manually once
Open the automatic actions list, locate the action that creates tickets from recurrent definitions, and run it manually from its detail page instead of waiting for the next cron cycle. Keep the result visible, because it reports how many tickets the action created and records any error. Done when the action reports the expected number of created tickets, which should match the definitions you configured, and the definition's next creation date has advanced.
Verify the generated ticket and SLA start
Open the ticket the run created and check the title, description, category, entity, assigned group and request type against the template. Confirm the SLA is attached and that its time-to-own and time-to-resolve dates start from the ticket's opening time and follow the SLA calendar. Done when every field matches the template, the SLA dates agree with your calendar, and you note the ticket reference in the change record for the first run.
Confirm the schedule on the next occurrence
Leave the definition active and let the scheduled cron run create the next ticket without manual intervention. Compare its creation time, fields and SLA dates with the first ticket and with the calendar you chose, and record any difference. Done when the second ticket appears on the expected date with the same configuration, and the team that receives the work has confirmed it appears in their queue.
Which routine work fits recurrent tickets or changes
Some routine work is performed by an operations team, produces a result and does not alter the production environment. Backup restore checks and monthly reporting runs fit this pattern. A recurrent ticket gives each occurrence its own record, so the team can show that a check happened, who performed it and what it found. Illustrative example: a restore test of the database backup runs on the first working day of each month, creates a ticket in the infrastructure entity and is assigned to the on-call operations group. The ticket closes once the test result is written in the solution.
- Backup restore checks: Each occurrence records the restored system, the date and the outcome, which gives auditors a dated trail.
- Monthly reports: A ticket per cycle shows that reporting happened on time and keeps the output attached to the record.
- Assignment: Route each occurrence to the group that does the work, not to an individual who may leave the team.
- Entity scope: Place the template in the entity that owns the system so that tickets reach the right service desk.
- Follow-up: Failed checks should open a separate ticket or problem, so the recurring record stays a clean log.
Before building these, confirm with your operations leads which tasks they already track elsewhere and which recurrence cycle each one follows.
Scheduled maintenance windows change production systems, so they usually need a validation step before work begins. A recurrent change creates a change record on the schedule you define, and the record can carry approval requests to the people who must agree. This keeps the approval history with the change instead of in an inbox. Illustrative example: a monthly patching window for a set of application servers creates a change in the production entity, sends a validation request to the change manager and records the outcome before the window opens.
- Maintenance windows: Each occurrence carries its own planned start, end and affected items, which supports later review.
- Approval steps: Validation requests attach to each generated change, so approvers see the same fields every cycle.
- Quarterly access reviews: A review change can list the groups or accounts under review and hold the decisions as evidence.
- Calendars: Confirm which business calendar and holiday rules apply to each change, since the schedule must match the change freeze policy.
- Template upkeep: When systems are retired or renamed, update the template or the linked items, or old occurrences will point to stale assets.
Before relying on this pattern, confirm with your change manager which changes are standard, which need approval and who must sign each validation step.
Most organizations have more routine work than they expect, and the same task can fit either pattern depending on its effect. The useful question is whether the occurrence alters a production system or a control, and whether someone outside the performing team must approve it. Map each routine task against three needs: the entity that owns the system, the approval path, and the calendar that defines working days and blackout periods. Keep the list short at first, then extend it after the first cycles show what the team actually needs.
- Entity mapping: Record which entity owns each system so that generated items land in the right queue and reporting boundary.
- Approval mapping: Note whether the task needs a validation request, and who signs it, before you choose ticket or change.
- Calendar mapping: Identify the calendar that governs due dates, including public holidays and maintenance freezes.
- Recurrence mapping: Write down the cycle, such as monthly or quarterly, and who owns the next occurrence if the owner changes.
- Evidence mapping: List what an auditor or manager would ask to see for each task, and make sure the template captures it.
Ask your service management owner to review this map against your existing change policy before creating any templates.
Security and operational risks of recurring work
Recurring tickets and changes run unattended, so a failure often shows up as a missing ticket rather than an error message. The cards below cover the risks that tend to stay hidden until someone audits the queue, and the controls that keep the schedule honest.
Duplicate or missed generation after upgrade
Recurring ticket creation runs from scheduled automatic actions, and an upgrade changes the code and database that those actions depend on. Before and after each GLPI update, record how many recurrent tickets should exist per period and compare that count after the first scheduled run. Under the update procedure, plugins are suspended after a new version is detected and must be reactivated after major updates, so any plugin that generates recurring work needs a manual check.
Automatic actions silently stopped
Recurring work depends on the GLPI cron task being triggered and on the individual automatic action being enabled. If the trigger stops, no error appears in the ticket list, and the gap only shows when a routine task is found missing. Monitor the last run time and the status of the automatic actions that create recurrent items, and alert when a run is overdue. Confirm how your server schedules GLPI's cron entry, since this depends on your deployment.
Templates exposing content across entities
A recurrent ticket or change copies its template content, including descriptions, linked assets and attached instructions, into every new item it creates. If a template is written in one entity but generates items for another, sensitive details such as hostnames, credentials locations or customer names can reach the wrong audience. Restrict who can edit templates, review the entity each template targets, and test one generated item in each entity before enabling the schedule.
Recurring changes reused without review
A recurring change is approved once and then generated again on each period, so the approval may no longer reflect the work being performed. Schedule a periodic review of each recurrent change template against the current systems and the current change policy, and record the review date in the template. Confirm with your change governance owner whether generated changes still need individual validation or only a review of exceptions, since your policy decides this.
Access to template edit rights
Whoever can edit a recurrent template can change what every future ticket or change says and who receives it. Grant template editing to a small named group, separate it from the group that works the queue, and log changes to templates through your normal administrative review. Check the profile and entity rights of each template owner during access reviews, because a rights change for one person changes every schedule they own.
Limits to confirm in your GLPI environment
Recurrent tickets and changes depend on version-specific behavior that the supplied sources do not settle. The cards below list what to confirm in your own GLPI instance before you commit to a schedule, a template or a validation design.
Maximum recurrence granularity
Confirm the shortest and longest periodicity your GLPI version offers for recurrent tickets and recurrent changes, including whether intervals such as hourly, weekly, monthly or yearly are available. Check whether a custom interval is possible for work such as a quarterly restore test. Record the answer against the exact version you run, because periodicity options have changed between major releases and you will be planning across upgrades.
Behavior when a calendar excludes the day
Test what happens when the scheduled date falls on a day the assigned calendar marks as closed, such as a public holiday or a maintenance freeze. Confirm whether the occurrence is skipped, moved to the next open day or created on the original date with the SLA clock set accordingly. This matters for backup verification and monthly control tasks, where a silently skipped run can leave a gap in your evidence trail.
Time zone handling
Confirm which time zone GLPI uses to compute the next occurrence, whether it comes from the server, the user profile or the entity, and how daylight saving changes shift the creation time. Check the time zone of the automatic action that generates the tickets, since a run scheduled near midnight can create work on the wrong date for a distributed team. Test with a recurrence that crosses a clock change.
Behavior across entities
Confirm which entity a recurrent ticket or change is created in when the template belongs to a parent entity and the work applies to a child entity. Check whether assignment rules, SLAs and calendars from the child entity apply to the generated item. Recurrences that span entities can route work to the wrong queue or leak visibility between customers, so test with two entities before rollout.
Validation steps on recurrent changes
Confirm whether a recurrent change created from a template carries the same validation stages, approvers and approval ordering as a manual change. Check whether each generated occurrence requests a fresh approval or inherits the approval from the first one, and who is notified when an approval is pending at the time of the next run. For changes that touch production, an approval gap is a control issue, not a scheduling detail.
Automatic action and queue reliability
Confirm which automatic action generates recurrent items, how often it runs in your environment and whether a failed or stopped run is visible to administrators. Check whether a missed run is caught up later or lost. Document the expected run interval and monitor it, because recurrent work that depends on a cron-driven task stops quietly when that task is disabled or the server is down.
Questions teams ask before setting up recurrent work in GLPI
How much effort does it take to build templates and schedules for a routine catalog?
The effort scales with how many routine items you have and how much each one differs from the next. Each recurring item needs a ticket or change template with the right category, urgency, assigned group, description and checklist, plus a periodicity and, where it matters, a calendar that decides which days the work is created. Most of the time goes into agreeing the catalog itself: which tasks recur, who owns each one, and what evidence the team must attach when it closes. Ask any partner to split the estimate into catalog design, template build, schedule configuration and testing, so you can see where the hours sit before you approve a written scope.
What drives the cost of recurrent ticket and change work in GLPI?
Cost follows the number of distinct recurrences, the approval paths attached to them, the entity structure that decides where tickets land, and the testing required before go-live. Each additional approval stage on a recurrent change adds configuration and test cases. Multiple entities with different groups and calendars multiply the rules you must verify. Costs that recur are usually the review of the catalog when processes change and the upkeep of templates after GLPI upgrades. Ask for a quote that lists these drivers as separate line items so you can remove optional parts without guessing.
What does our team need to provide before the work starts?
The work depends on decisions only your organization can make. Provide named process owners for each routine item, the working calendars and holiday rules that should shift or skip occurrences, and the exact names of the groups that will receive tickets. Also provide a test environment that mirrors your production GLPI version, plugins and entity layout, because recurrence logic should be checked there before it creates real work. Confirm who approves changes to the catalog and how long a template may stay unchanged before review.
Can an internal team set up recurrent tickets and changes alone?
Yes, a team with GLPI administration skills can configure recurrent tickets and changes without outside help, especially for a small catalog with one entity and no approval chains. The risk lies in untested schedules that open duplicate work, skip due dates over holidays or send changes to the wrong approvers. Teams that do it alone usually benefit from a written catalog, a test environment and a second reviewer who checks each template. A partner is most useful when the catalog is large, spans several entities or must be documented as evidence for an audit.
What does recurring maintenance of a GLPI recurrence setup look like?
Maintenance has two layers. The first is routine review: checking that scheduled items still match current processes, that owners and group names are correct, and that the automatic action that generates recurrences is running and has no errors in its logs. The second is upkeep after GLPI upgrades, when templates, plugins and the automatic action behavior should be retested in the test environment before production. Plan the review cadence and assign an owner for it. Support and upgrades can be covered by a retainer if your team prefers not to carry them.
Does a recurring task produce evidence that auditors will accept?
A recurrent ticket records that a task was scheduled, assigned, worked and closed, which can serve as operating evidence for routine controls such as backup checks. Whether an auditor accepts that record depends on the control wording, your retention rules and how consistently the tickets are closed with results attached. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Ask your assessor early which evidence they expect for each routine item.
Which GLPI version and database should we confirm before building recurrences?
Confirm the GLPI version first, because the recurrence behavior and the update path differ across releases. Supported versions in the researched facts include GLPI 11.0 and GLPI 12.0.0, with requirements listed in the installation documentation for prerequisites. Check the PHP and database versions against the prerequisites page and confirm which plugins you rely on, since in GLPI 11 plugins are suspended after a new version is detected and must be reactivated after major updates. Build and test the recurrence catalog on the same version you will run in production.
How DeployOpen scopes and delivers recurring work
Recurring work is scoped as a written catalog before any template is built. DeployOpen's fixed-scope approach starts by listing every routine item the client wants automated, such as backup restore checks, monthly patch reviews, certificate renewals and access reviews, and recording for each one the ticket or change type, the category, the assigned group, the periodicity, the calendar that decides which days count, and the approver where a change is involved. The same document fixes which templates are reused and which fields are mandatory, so the reviewer can see the whole schedule in one place. Ask your team to confirm which entity or group owns each routine item, because that answer decides the approval path and whether a change needs a Change Advisory Board step.
Templates, calendars and approvals are agreed in writing, then tested in a non-production instance. Before go-live, the recurring definitions are created in a staging GLPI installation that mirrors the production configuration, and the team checks what the automatic action generates on a realistic date range, including month ends, public holidays and days when a calendar excludes work. Tests should confirm that generated items carry the right template, that approvals stop changes from advancing without a decision, and that nothing is created twice when the action runs late. Plan for the staging instance to be a copy of production configuration rather than production data, and confirm with your security team how that copy is handled.
The handover covers documentation and runbooks, and support can continue as a retainer. At the end of the fixed-scope work, DeployOpen hands over the routine catalog, the configuration record for each recurring definition, the test results and a runbook for changing a schedule, pausing an item during an outage or restoring a deleted definition. Teams that want someone to watch the automatic action after go-live, review the generated queue and handle upgrades to the recurring logic can request ongoing support as a retainer, which is scoped separately from the original delivery. Ask for the monitoring and response expectations in writing before you choose that option.
How DeployOpen works on GLPI recurrence
The sequence moves from an inventory of routine work to a tested set of recurrent tickets and changes that your service desk runs without rebuilding them each cycle. Each phase ends with a written artifact that the next phase depends on.
Inventory the routine work
DeployOpen works with your service desk and infrastructure leads to list every task that repeats: backup verification, patch windows, certificate renewals, monthly reporting and licence reviews. For each item we record the owner, the group that handles it, the trigger or periodicity your team uses today, and whether the work is a ticket (a request or incident-style task) or a change that needs approval. The output is a signed-off register of recurring items that shows which ones need a change path and which ones need a calendar.
Design templates and calendars
For each register entry we design the recurrent ticket or change template, including category, urgency, assigned group, description text, mandatory fields and any checklist the technician must complete. We then define the periodicity and the working calendar that decides which days count, and agree how a missed occurrence is handled. Your team reviews the design document before anything is built, so the output is an approved template specification per item and a calendar definition your operators can read.
Build the recurrent items in a test instance
We configure the templates, periodicities and calendars in a non-production GLPI instance on infrastructure you control, using the GLPI version your organization has chosen. We check that the automatic action responsible for generating recurrent items is enabled and running on the schedule your environment supports, and that entities, groups and profiles resolve to the right people. The output is a build record listing each recurrent item, its configuration and the test instance it was verified on.
Test occurrences and edge cases
We run each recurrent item through its expected cycle and through edge cases: a calendar holiday, a closed or pending previous occurrence, a changed owner, and a template field left blank. We confirm that a new occurrence is created only when the rule says it should be, that notifications reach the right group, and that reports and SLA timers behave as the service desk expects. Failures go back to the build phase. The output is a test log with a pass or fail result for every scenario and your sign-off on the exceptions you accept.
Cut over to production
We schedule the production change with your team, load the approved templates and calendars, and disable the spreadsheet, calendar reminders or manual lists that previously tracked the same work so that two systems do not create duplicate tasks. We watch the first live occurrences and confirm that the first generated items match the test results. The output is a cutover record with the date of activation, the list of retired manual reminders and the first verified occurrences.
Hand over with runbook and checks
We deliver a runbook covering how to pause, edit or retire a recurrent item, how to read the automatic action log, what to do when an occurrence is not created, and who approves changes to templates. We walk your operators through the runbook and agree a periodic check, run by your team, that confirms the scheduled items are still generating as intended. The output is the signed runbook, the list of owners and a checklist your team can repeat without DeployOpen.
