Understanding and configuring the GLPI notification queue

The notification queue

Have you ever had a colleague tell you they never received a notification for an action you just performed? Or have you experienced receiving several emails in a row regarding the same ticket?
The answer to both questions usually lies in the same place: the GLPI notification queue. Understanding how this queue works is one of those things you won’t think about when everything is going well. However, the moment issues arise, knowing how to read it turns a confusing problem into a quick diagnosis.

How the notification queue works

It is fundamental to understand that every single email notification generated by GLPI without exception must pass through the notification queue before being sent. There is no Quick send option that bypasses this system. GLPI adds the notification to the queue, and an independent process handles the actual delivery. This ensures a detailed record of every message and provides diagnostics for delivery failures.

GLPI‘s notification queue ensures every message is sent, providing a detailed record for any delivery failures to simplify monitoring and diagnostics.

Notification configuration

Understanding the notification delivery mechanism

To send email notifications, we need an SMTP server.

What actions generate notifications?

The queue does not send emails on its own. Instead, GLPI uses two specific automated actions to manage the sending and cleanup processes. While developers refined these functions in version 9.2, you must remember that GLPI does not enable all notifications by default; you may need to activate some manually.

Setup → Notifications → Notifications 

Who receives the notification?

For every action, you can configure the specific recipients. Common recipients include the Administrator, Requester and Watcher.

The automatic actions

Two GLPI automatic actions manage the sending process. GLPI 9.2 updated their names and refined their functionality. You can find them under:

Administration → Automatic actions.

QueuedNotification

• Responsible for processing pending entries and attempting SMTP delivery.
• In each execution, it collects all entries whose scheduled delivery time has passed and attempts to deliver them.

If notifications stop arriving, check that this is “Active” and its “Last run” is recent.

QueuedNotificationClean

The QueuedNotificationClean automatic action is responsible for sanitising the database by permanently removing processed entries from the notification queue. Its operation is governed by the following logic:

• The task identifies notifications that have been successfully dispatched and are no longer required for immediate auditing.
• Days to keep sent emails field: The system marks any notification for deletion if it exceeds the configured number of days.

Controlling notifications: The delay feature

GLPI allows you to configure a notification delay per entity. When configured, queue entries for that entity will not be eligible for sending until the specified delay has elapsed since their creation.

Why would you delay notifications?

• Avoid sending unwanted notifications: A delay creates a crucial window of time for detecting errors. This delay allows us to eliminate potentially unwanted notifications.
• Centralised Control per Entity: Defining the notification delay at the entity level allows you to customise this parameter for each department/client/location independently.

Conclusion

Every e-mail notification in GLPI passes through the notification queue, but understanding how it truly works is what turns a confusing issue into a quick diagnosis. Properly configuring automated tasks and delay times ensures professional, fluid communication, and knowing where to look when something goes wrong saves time for everyone involved.
That said, it is worth keeping in mind that certain plugins may include their own notification logic and can be configured to bypass the queue entirely, sending messages directly via SMTP. In those cases, queue-based diagnostics will not capture those messages, so it is important to account for this when investigating missing or unexpected notifications.