Troubleshooting the GLPI notification queue

Why GLPI notification emails stop leaving the queue

When tickets are created but users, technicians or approvers receive nothing, the problem is rarely the ticket itself. GLPI does not send notification emails at the moment an event happens. It writes each notification to a queue in its database, and a scheduled automatic action, queuednotification, reads that queue and hands the messages to your mail transport. A message can therefore stall in at least three places: the event never produced a queued notification because the notification rule or recipient did not match, the automatic action never ran or failed while running, or the mail server rejected the message. Each place leaves different evidence, so the first job is to find out which stage is failing before changing any setting.

Teams usually need this troubleshooting in three situations: right after a new installation, after the mail server, relay or authentication details change, and after a GLPI upgrade, when the scheduler, cron setup or configuration may have changed. A healthy queue is one where new notifications are sent within the interval set for the automatic action, the number of pending entries stays low and does not grow between runs, and failed entries are rare and have a readable reason. Your own environment sets the baseline, so record the queue state and the send interval while mail works, then compare against that record. Confirm the exact configuration keys and the behavior of your GLPI version in the installation documentation before you rely on them.

How to check SMTP before touching the queue

This sequence separates a mail transport problem from a queue problem, so you know whether the notifications are stuck in GLPI or failing on the way out. Each step ends with a check that tells you whether to move on or stop and fix the layer you are on.

Confirm the sender and SMTP settings in GLPI
A GLPI administrator opens the notification and mail settings in the GLPI console and records the sender address, SMTP host, port, encryption mode and authentication user. Compare each value with what the mail relay team expects for this GLPI host, and note any mismatch before testing. The step is done when the settings in GLPI match the relay's documented values for this application and you have a written copy of them to compare against later.
Send a test notification from GLPI
Using a test account whose mailbox you control, trigger a test notification from the GLPI mail configuration screen, then watch the notification queue for the resulting entry. Record whether GLPI reports a successful send, an error message or no visible result. The step passes when the test message arrives in the target mailbox. If it does not arrive but GLPI shows an error, the fault is probably in transport or authentication, so continue to the connectivity check rather than the queue.
Check outbound connectivity to the mail relay
From the GLPI host itself, not your workstation, a systems administrator tests a TCP connection to the configured relay host and port, for example with a standard network client such as nc or openssl s_client. Run the same test from the web server or PHP runtime user context if the host uses separate network policies. The step passes when the connection opens and the relay returns its greeting banner. A timeout points to firewall, routing or DNS rules rather than GLPI.
Review TLS and authentication settings
Confirm with the mail team which encryption mode the relay requires, such as implicit TLS or STARTTLS, and whether it requires authentication for this sender. Check that the certificate chain is trusted by the GLPI host and that the credentials in GLPI are current and not locked. Ask the relay team to confirm the port and mode in writing if the documentation is unclear. The step passes when a manual SMTP session from the GLPI host completes the TLS handshake and authentication with the same settings GLPI uses.
Check the mail server logs for rejections
Ask the mail operations team for the relay or gateway logs covering the time of your test notification, and search for the sender address, the recipient and the GLPI host address. Look for rejections such as authentication failure, sender policy refusal, recipient policy refusal or size limits. Record the exact reply code and text, since that text usually names the policy that blocked the message. The step passes when the logs show the test message accepted for delivery. If the relay rejected it, fix the policy on the relay side before changing anything inside GLPI.
Decide whether the fault is in the queue
Once a test message has left GLPI and been accepted by the relay, the transport layer is no longer the suspect. Compare the queued entries still waiting in GLPI with the test result, and if new notifications are still stuck, move to the queue troubleshooting steps. If transport checks failed at any step, stop here, document the failing layer and reason, and fix it before touching the queue. Clearing or resending queued messages while SMTP is broken only repeats the failure.

Which failure pattern matches your symptoms

When the queue stays empty after an event you expected to notify, the message never reached the queue. GLPI creates a queued notification only when an event matches an active notification, the notification conditions pass for that object, and at least one recipient resolves. Nothing downstream, including SMTP, can fix this, so start with the event side.

Notification inactive or unmatched. Confirm the notification is active and that its event and conditions match the ticket or object that changed.
Notification mail disabled. Check that the notification mail setting in the configuration is enabled. If it is off, GLPI does not generate messages.
Recipients resolve to nobody. A notification whose actor, requester or group targets have no email address creates no queued message.
Known test event. Update a test ticket assigned to a user with a valid address and watch whether a row appears in glpi_queuednotifications.

Check the notification and its recipients first, because a message that was never queued cannot be recovered by fixing the mail server.

When rows accumulate in glpi_queuednotifications and their sent status never changes, the queue is working but nothing is processing it. The usual causes are the queuednotification automatic action not running, or the mail transport failing on each attempt. The mail server log separates the two quickly, so read it before editing GLPI settings.

Automatic action not scheduled. Open the automatic actions screen in Setup and confirm queuednotification is active, and check its last run date and any recorded error.
Cron not calling GLPI. If your instance runs automatic actions from cron, confirm the cron job runs as the web server user and that its output is logged.
SMTP connection failure. Review the host, port, encryption method and credentials on the mail configuration page, then send a test message from that page.
Server rejection. Permanent 5xx responses from the relay point to sender policy, recipient policy or authentication. The mail server log shows the exact reply.
Retry state. Entries that repeatedly fail may carry a failed state, so check the row status before assuming the action is idle.

Trigger the action manually once and compare the result with the mail server log, because that comparison shows whether the fault is in scheduling or transport.

Sometimes the queue drains normally until one notification is reached, then every later message waits behind it. This pattern often comes from PHP memory exhaustion while GLPI renders a notification with a very large body, such as a long ticket history, many followups or large embedded content. The batch that runs queuednotification stops partway, and the same entry is picked up again on the next run.

Same entry at the front. The queue size does not fall and the earliest unsent row stays the same across runs.
Memory error in logs. The cron output or PHP error log contains an "Allowed memory size exhausted" message that names the GLPI file being processed.
Oversized content. Notifications that pull full histories or large HTML bodies need more memory during rendering than short alerts do.
Different PHP configuration. The memory_limit for the command line can differ from the web server setting, so test the limit that the cron process actually uses.
Identify the row. Find the unsent entry with the largest content and note its object, so you can confirm that object is the source.

Confirm the exact error text before raising memory_limit, because a larger limit only hides an oversized message and can make later runs slower.

How oversized queued messages exhaust memory_limit

A single oversized queued notification can stop the entire mail queue. When the queuednotification automatic action builds a message, it loads the message body, the ticket history it renders and any attachments into PHP memory. A ticket with a long followup thread, a large HTML body or several attachments can push that process past the PHP memory_limit. PHP then terminates the run with a fatal error before the item is marked as sent. The next run picks up the same item in the same order, fails in the same place, and every notification queued behind it waits. The symptom is a queue that grows while the action log shows repeated failures rather than a clean run.

To find the offender, start with the queue itself. Review the queued notification table in the GLPI database, sorted by creation date, and look for the oldest entries that have not been sent, especially those tied to tickets with unusually long histories or large attachments. Compare the first failing run in the automatic action logs with the item GLPI was processing at that moment, and check the PHP error log on the web or CLI host for the memory exhaustion message and its file reference. Confirm the exact table names and log locations against the GLPI version you run, since these details can change between releases. Test the suspect item in a copy of the instance before you change anything in production.

Raising memory_limit is the quickest fix and the one most likely to hide a problem. A higher limit applies to every PHP process on the host, including the web tier, so it can increase the memory each request may consume and reduce capacity during peaks. Confirm the new value with the platform team, who own the PHP-FPM or Apache settings, the host sizing and any shared servers, and agree how the change will be tested and reverted. Shrinking the message is often the better route: remove or link large attachments, or review the ticket history that is being rendered. Deleting queued items is a last resort and needs a backup and a sign-off from the business owner of the affected tickets.

Clearing the queue safely without losing notifications

Clearing a stuck GLPI notification queue is the last step, not the first. The cards below run in order: protect the data, record what is waiting, fix the cause, prefer resending over deleting, pick a quiet window, and leave an audit trail.

Back up the database first

Take a database dump before you delete or edit anything in the queue, because the queued notification rows live in the same database as tickets, users and configuration. Confirm the dump is complete and readable by restoring it to a scratch database or checking its size and table list. If the backup fails, stop. A queue flush that cannot be reversed is the most common way to lose notifications that were otherwise recoverable. The backup procedure itself is covered in a sibling topic.

Export the queued items

Before any change, export the pending queue rows to a file, including recipient, subject, creation date, and the related item type and ID. This gives you a list to compare against after the fix and a record of what was waiting. Use a read-only query so the export does not change the queue. Keep the file with the change record, since it is the only list of what was pending if a later step goes wrong.

Fix the root cause before flushing

Flushing a queue that is still failing only fills it again or repeats the same error. Confirm the SMTP settings, the queuednotification automatic action, and the PHP memory limit against the messages that are stuck. If oversized messages are exhausting memory_limit, identify and handle them first, otherwise they will block the next batch. Once a test message leaves the server and the action completes cleanly, the queue is ready to be cleared.

Resend or mark before deleting

Prefer options that keep a record of each notification. Where your GLPI version lets you reprocess queued items, resend them after the fix. Where a message is no longer relevant, mark it as handled rather than removing the row. Delete only items you have confirmed are duplicates, test messages or expired, and only after the export exists. This keeps the notification history intact for the people who depend on it, such as requesters waiting for a ticket update.

Avoid mass deletes in business hours

Schedule the flush for a window when few tickets are being created or assigned, and when the team can watch the next automatic action run. Deleting or resending a large batch during peak hours can flood recipients with late messages or hide new failures under old ones. Confirm who will monitor the queue and mail server during the window, and agree in advance how to stop if the first batch misbehaves. Ask the business owners of the ticket workflow to approve the window.

Document what was dropped

Record every deletion in a change log: the date, the operator, the queue count before and after, the reason for each group of removed items, and the location of the export and backup. Auditors and incident reviewers often ask whether a notification was lost, and a dated record answers that question without guesswork. Also note any messages you resent, so the recipients and the audit trail match.

Fix options and when each one fits

This table compares the five common fixes for a GLPI notification queue that stops sending, from correcting SMTP settings to purging the queue. Read each row against the symptom you see: a failing SMTP test points to the first row, while a queue that grows but never drains points further down. The main takeaway is that purging is the last resort, because it discards messages that may still be needed.

Option	When it fits	Risk	What to confirm
Correct SMTP settings	The SMTP test in the GLPI setup fails or the mail server log shows rejected connections from the GLPI host	Wrong credentials or relay rules can lock out other mail senders if changed in a shared account	Host, port, encryption mode and sender address with the mail team, and that the GLPI host is allowed to relay
Run queuednotification manually from the console	The action is scheduled but queued messages stay unsent, and you need to see the error output in the foreground	Sending a large batch at once can hit SMTP rate limits or flood recipients with delayed alerts	The action's current state and last run in the GLPI console, and that the command runs as the web server user
Adjust PHP memory_limit for CLI and web contexts	Logs show memory exhaustion while processing a large queued message, and the CLI and web limits differ	Raising the limit too far can hide a bloated message and affect other PHP workloads on the host	The effective memory_limit for the CLI php binary and the web SAPI, and the size of the largest queued message
Split or trim notification content	Specific notifications carry large attachments, full ticket histories or embedded images that exceed mail server limits	Changed templates may drop information recipients rely on, and edits need review by the service desk	Which event templates produce the large payloads and whether the mail server enforces a message size limit
Purge the queue	Messages are obsolete, duplicated or cannot ever be delivered, and the queue is blocking newer alerts	Permanent loss of pending alerts, including security or outage notices that someone still expects	A saved copy of the queue table, sign-off from the process owner, and a list of affected recipients

Security and operational considerations for mail in GLPI

Notification email touches credentials, personal data and the queue itself, so each of these needs a deliberate owner. The cards below cover the controls to set before and during a queue incident, so that fixing delivery does not create a new exposure.

SMTP credential storage and rotation

The SMTP account password is stored in GLPI's mail configuration, and GLPI encrypts sensitive configuration values with the keys held in glpi.key. Use a dedicated sending account rather than a personal mailbox, and confirm with your mail provider how it issues and revokes application passwords or OAuth tokens. Record who can change the password, and rotate it on a schedule that matches your identity policy and after any staff change. Test the new credential with the SMTP check before you retire the old one.

Avoiding an open relay

A GLPI server that accepts unauthenticated submission from the network can be abused to send spam under your domain. Allow SMTP submission only from the GLPI host, require authentication on the relay, and restrict outbound ports from the web and database tier. Confirm that the sending domain has SPF, DKIM and DMARC records that match the relay you actually use. Review the relay logs after any queue flush, because a sudden burst of messages can be a sign of misuse.

Personal data in notification content

Notification bodies often contain requester names, ticket descriptions, asset owners and sometimes free-text details that users typed into a ticket. Those messages sit in the queue table until they are sent or purged, so the queue is a store of personal data in its own right. Decide which notification templates may include ticket content and which should send only a link back to GLPI. Document the retention period you expect for queued messages, and confirm it with your privacy team.

Limiting who views and purges the queue

Viewing the notification queue and deleting its entries should be separate permissions in your profile design. Restrict those rights to a small group of administrators who handle mail support, and check that helpdesk or self-service profiles cannot reach the queue screens. Clearing queued messages without a record can hide evidence of a failed alert, so require a named approver for any bulk purge. Review the assignment of these rights during each access review.

Logging changes made during an incident

During an outage, administrators often change the SMTP host, edit notification templates, reactivate automatic actions and delete queued messages in one session. Record each change with the time, the person, the old value and the new value, in your change system or a shared incident log. Export or copy the affected queue rows before deleting them, so you can explain later which messages were dropped. Restore the normal configuration after the incident and confirm that the record matches what GLPI shows.

Keeping the mail path under change control

Changes to the mail relay, the sending domain, the GLPI mail collector and the cron schedule each affect delivery in different ways. Treat them as separate change items with their own rollback step, and test a single outgoing message after each one. Ask your mail provider whether sending limits or policies apply to your account, since a configuration change can trigger throttling. Keep a short runbook that names the owner of each mail component so that the next incident does not start with a search for the right person.

Questions teams ask before fixing GLPI email on their own

Can an internal GLPI administrator fix the notification queue without outside help?

Often yes, if the administrator can read the GLPI logs, check the SMTP settings and run console commands on the server. Most stuck queues come from a mail relay that rejects connections, a credential that changed, a scheduled action that stopped running, or a queue that grew past what PHP can load in one pass. Each of these can be diagnosed in order. The harder cases involve mail relay policy owned by another team, a database that has grown large, or a queue that must be cleared without losing messages a user is waiting for. Those are the points where an internal team usually benefits from a second pair of eyes.

How long does a GLPI notification queue fix take?

The duration depends mainly on where the fault sits. A corrected SMTP host or credential and a re-run of the queued notification action can be verified in a short session. Duration grows when the cause is in the mail relay, when the queue holds many oversized messages that must be removed one batch at a time, or when the team must first agree on what to do with stale notifications. Confirm with your own environment which of these applies before you plan a window. Any timeline in a written scope should reflect a check of your mail path, not a generic estimate.

What does a partner need from our team to start?

A partner works faster when your team provides the GLPI version and the PHP and database versions in use, shell or console access to the GLPI host, read access to the web server and PHP logs, and the SMTP relay details including the authentication method and allowed sending hosts. It also helps to have the mail administrator on call, a current backup, and a list of which notifications matter most to your service desk. Access should be agreed in writing before work starts, and any production change should follow your own change process. DeployOpen works inside your infrastructure, so these details stay with your team.

Does clearing the notification queue delete tickets or lose data?

Clearing queued notifications removes pending outbound emails, not tickets, assets or the records that triggered them. The ticket and its history remain in the database, so a user can still see the update in the GLPI interface. The risk is that a stakeholder never receives an alert they expected. Before clearing anything, export or record the queued rows, confirm a current database backup exists, and decide whether to resend important notices manually. Make the change in a maintenance window if the queue is large, and document what was removed and why.

What does a GLPI email fix cost, and what drives the price?

DeployOpen does not publish a price list, so a quote follows from the written scope. Cost is driven by the number of systems involved (GLPI host, database, mail relay and any proxy), how many separate causes must be proven, the size of the queue, whether changes are needed on infrastructure owned by other teams, and how much knowledge transfer your team wants. One-time work covers diagnosis, the fix and verification. Recurring costs appear only if you add ongoing support or monitoring under a retainer. Ask any provider for the components listed separately, the assumptions about access and change windows, and what is excluded.

How do we scope a quote for a GLPI notification queue engagement?

Start with a written description of the symptom, the GLPI and PHP versions, the mail relay in use and the number of users affected. Then list the systems you can give access to and the change windows you can offer. Ask the provider to state the diagnostic steps, the remediation actions, the verification tests and the handover items, along with what is out of scope, such as relay configuration owned by a third party. Most engagements are fixed-scope, so the agreed deliverables and timeline should appear in writing before work begins.

Which GLPI versions should we check before troubleshooting email?

Check the version you run before changing anything, because the supported PHP and database versions differ between releases. The GLPI README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later on the main branch, while the installation docs list PHP 8.2 or later for GLPI 11.0. Confirm your versions against the GLPI installation prerequisites and plan any upgrade separately, since a mail fix should not be combined with a version change without a tested rollback.

How DeployOpen works on this

DeployOpen approaches GLPI notification queue troubleshooting as a bounded piece of work inside your own infrastructure. We start from the symptoms, the mail path and the queue state, then agree a written scope before any change is made to your instance.

How we scope

Confirm your GLPI version, PHP and database versions, and how the web server and cron run the automatic actions.
Review the SMTP relay, sender settings, TLS and authentication path with your mail team before any test message is sent.
Agree in writing whether the work covers diagnosis only, a fix on your instance, or queue cleanup, since engagements are fixed-scope.

How we build

Trace one stuck message from the notification queue through the queuednotification action to the relay, recording each result.
Check memory_limit against the size of queued messages with attachments, and adjust settings or attachment handling as scoped.
Test the fix with controlled messages, and document the queue backup and clearing steps so they can be repeated safely.

How we hand over

Deliver a written runbook covering SMTP checks, action scheduling, queue inspection and the safe clearing procedure.
Walk your operators through the diagnostic commands and the logs that confirm mail is leaving the instance.
Record every configuration change, with before and after values, so your team can audit and reverse them.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which can cover queue monitoring after handover.
Ask any partner to confirm how mail issues are triaged, which logs are retained and who responds outside working hours.
Confirm with your own mail provider and GLPI release notes any behavior that depends on version, before you rely on it in production.