GLPI abre por sí solo los tickets de mantenimiento preventivo: limpieza de impresora, prueba de backup, cambio de contraseña de servicio, revisión de accesos. Probamos los tickets recurrentes de GLPI 11 y funcionan, pero tres detalles hacen que el preventivo desaparezca o salga mal sin ningún aviso. Una recurrencia mensual que empieza el día 31 pasa a caer el día 3. Una creación anticipada mayor que la periodicidad hace que GLPI nunca cree nada. Y una plantilla sin campos genera un ticket en blanco.
Para qué sirven los tickets recurrentes
Toda rutina que hoy depende de que alguien se acuerde:
- Mantenimiento preventivo de impresoras, UPS y aire acondicionado de la sala de servidores.
- Prueba de restauración de backup (el backup que nunca se ha restaurado no es backup; consulte backup y recuperación ante desastres en GLPI).
- Revisión trimestral de accesos y de cuentas inactivas.
- Renovación de certificados, licencias y dominios.
- Checklists de apertura y cierre de mes.
El ticket nace el día correcto, con categoría, grupo y descripción listos, entra en la cola y cuenta en el SLA como cualquier otro.
Cómo configurarlo
1. Cree la plantilla de ticket
El recurrente no tiene título ni descripción propios: lo copia todo de una Plantilla de ticket. En los campos predefinidos de la plantilla, complete como mínimo:
- Título y descripción (con el checklist de la tarea);
- Categoría y tipo (generalmente Solicitud);
- Grupo asignado, para que el ticket no nazca sin responsable;
- Urgencia o prioridad.
2. Cree el recurrente
En Soporte > Tickets recurrentes:
| Campo | Qué poner |
|---|---|
| Activo | Sí |
| Plantilla de ticket | La plantilla del paso 1 |
| Fecha de inicio | La primera ocurrencia (día y hora) |
| Fecha de fin | Opcional; después de ella, GLPI deja de crear |
| Periodicidad | De 1 hora a 10 años (horas, días, meses o años) |
| Creación anticipada | Cuánto tiempo antes de la ocurrencia debe abrirse el ticket (hasta 2 semanas) |
| Calendario | Opcional; traslada la creación al siguiente día y horario laborables |
En la pestaña de elementos, vincule los activos (la impresora, el servidor) para que el ticket nazca ya asociado a ellos.
3. Revise la acción automática
Quien crea los tickets es la acción automática RecurrentItems, que se ejecuta cada hora. En la práctica, el ticket puede aparecer hasta una hora después del horario programado. Si la hora exacta importa, use una creación anticipada de al menos 1 hora. Y el cron de GLPI tiene que estar en ejecución (consulte el paso 6 de cómo instalar GLPI 11).
La prueba: dónde sale mal la recurrencia
Usamos el propio cálculo de GLPI 11 para ver las próximas fechas en casos que suelen dar problemas, y creamos tickets reales en nuestra entidad de pruebas (datos ficticios, borrados después).
| Caso | Próximas fechas que calculó GLPI | Qué ocurre |
|---|---|---|
| Mensual que empieza el 31/01 | 31/01, 03/03, 03/04, 03/05 | Se desplaza al día 3 y se queda ahí para siempre |
| Mensual que empieza el 28/01 | 28/01, 28/02, 28/03, 28/04 | Correcto |
| Semanal que empieza un sábado, sin calendario | 10/10, 17/10, 24/10 (sábados) | Crea en fin de semana |
| Semanal que empieza un sábado, con calendario | 12/10, 19/10, 26/10 (lunes) | Salta al siguiente día laborable |
| Diario con creación anticipada de 2 días | ninguna (próxima fecha vacía) | Nunca crea nada |
| Plantilla con título y descripción | ticket creado con ambos | Correcto |
| Plantilla sin ningún campo | ticket creado con título y descripción vacíos | Entra en la cola un ticket en blanco |
Las tres trampas
1. Día 29, 30 o 31 en el mensual
En la periodicidad en meses, GLPI suma "1 mes" a la fecha. Febrero no tiene día 31, así que 31/01 + 1 mes se convierte en 03/03, y a partir de ahí la recurrencia sigue en el día 3. El preventivo "del último día del mes" se convierte en "del día 3".
Solución: comience las recurrencias mensuales entre los días 1 y 28. Si tiene que ser a fin de mes, use el día 28 y una creación anticipada.
2. Creación anticipada mayor que la periodicidad
En un recurrente diario con creación anticipada de 2 días, GLPI considera la configuración inválida y deja vacía la próxima fecha. En pantalla, el recurrente aparece activo; en la práctica, no crea nada.
Solución: la creación anticipada tiene que ser menor que la periodicidad. Después de guardar, compruebe que la próxima fecha de creación se haya completado.
3. Plantilla sin campos
Si la plantilla no tiene título ni descripción, GLPI crea el ticket igualmente, en blanco. Nadie sabe qué hacer con él, y se queda parado en la cola.
Solución: título, descripción, categoría y grupo en la plantilla, siempre. Y abra el historial del recurrente: cada creación deja un mensaje, incluso cuando falla.
Buenas prácticas
- Un recurrente por rutina, con el nombre de la rutina y la periodicidad en el nombre ("Preventivo impresoras - mensual").
- Checklist en la descripción, con qué hacer y cómo registrar el resultado.
- Calendario con festivos para no crear tickets en días sin actividad: consulte cómo generar y vincular calendarios de festivos.
- SLA de resolución proporcional: un preventivo mensual no necesita el SLA de un incidente.
- Revisión trimestral de la lista de recurrentes: equipo sustituido, rutina que cambió, fecha de fin vencida.
- Los cambios también pueden ser recurrentes (Soporte > Cambios recurrentes), para ventanas de mantenimiento planificadas.
Prueba de NexTool el 4 de octubre de 2026, en el GLPI 11.0.7 de nuestro soporte, entidad de pruebas con datos ficticios. Las próximas fechas se calcularon con la función del propio GLPI; las plantillas, los recurrentes y los tickets de prueba se borraron al final.
Comentarios
Los comentarios de esta publicación vienen de GitHub (giscus). Al cargarlos, tu navegador se conecta a GitHub, que recibe tu dirección IP y puede guardar sus propias cookies.
Para cargarlos automáticamente, activa las cookies funcionales