You've set up notifications, test emails arrive, everything looks good — except the link to the ticket is missing. Users get "Ticket URL: " followed by nothing. It's one of the most common beginner issues with GLPI notifications, and the fix takes 30 seconds once you know where to look.
The cause
GLPI builds ticket URLs by prepending the configured base URL to the internal path. If the base URL isn't set, the ##ticket.url## placeholder resolves to an empty string. A typical notification template fragment:
##lang.ticket.url## : ##ticket.url##Without the base URL configured, this renders as:
Ticket URL :Nothing wrong with the template — GLPI just doesn't know what hostname to use.
The fix
Log in with an account that has super-admin rights, then:
- Go to Setup → General (in GLPI 10/11: Setup → General → General setup)
- Find the URL of the application field
- Enter your full GLPI URL, including the protocol and no trailing slash — e.g.
https://glpi.example.comorhttps://helpdesk.example.com/glpi - Save
The next notification will render the URL correctly. Existing queued notifications fire with the old (empty) URL — those are already rendered into the database. If you need to fix a queued batch, delete them from Setup → Notifications → Notification queue before GLPI sends them.
Why this catches so many people
GLPI doesn't autodetect its URL from the web request. There are good reasons — reverse proxies, protocol rewrites, custom paths — but the downside is that a fresh install happily sends broken notifications until you set it manually.
Two patterns specifically trigger this:
- CLI-driven notifications — if you run GLPI's cron from the command line (see our GLPI cron guide), there's no HTTP request in scope for GLPI to guess the URL from. The configured base URL is the only source. If you migrated from the pseudo-cron to real cron and notifications "suddenly" lost their links, this is why.
- Reverse proxy setups — GLPI sees the internal address (e.g.
http://localhost:8080) but users access it externally. Always configure the external URL as the application URL, even if GLPI is bound to localhost behind nginx or Traefik.
Verify the fix
Trigger a notification — create a test ticket or run Test notifications from the notifications configuration page. Check the received email, click the link, and confirm it opens the correct ticket.
If the URL is still empty:
- Confirm the URL of the application value actually saved (GLPI silently drops invalid URLs)
- Check you're not in a staging environment reading notifications generated before the fix
- Look in
files/_log/mail.logto see the fully rendered message GLPI handed to the mail system
Related gotcha: HTTPS behind a reverse proxy
If your URL is HTTPS but GLPI sits behind a proxy that terminates TLS, you may also need to tell PHP to trust the proxy's forwarded headers. In config/config_db.php or via environment variables, ensure GLPI respects X-Forwarded-Proto. Otherwise links work but mixed-content warnings appear in browsers — another symptom of the same base-URL class of issues.