"Did the customer actually get our reply?" Every service desk hears it, and in Jira Service Management Cloud it is a surprisingly hard question. JSM sends notifications constantly, on request created, on public reply, on status change, and it keeps no searchable, retained record that any of them went out. The request for an outgoing email log, JSDCLOUD-4698, has been open for years with roughly 1,500 votes.
What the native tools actually answer
- The Customer Notification Log (Project settings, Customer notifications) looks like the log you want, and it is the first thing to check. The catch is in what it holds: only notifications that failed to send, with a reason. It is a bounce list, not a sent-items folder.
- Notification Helper answers a hypothetical about one issue and one recipient right now: would a notification be sent, and why or why not. It says nothing about what was sent last Tuesday.
- The notification scheme is where most "nobody got it" cases originate. Reviewing which events map to which recipients catches the silent misconfigurations.
None of these produce a retained, searchable history of successful sends, which is what a complaint, a dispute, or an SLA review actually needs.
The DIY approach: record the events that trigger notifications
Since JSM will not tell you what it sent, the durable approach is to capture the moments it decides to send. Every customer notification is driven by a Jira event you can observe:
- Subscribe to issue created, comment created (public replies and internal notes are distinguishable by the comment's visibility), and issue transitioned events through a webhook or, inside Forge, a product event trigger.
- For each event, resolve the recipient set: the reporter and request participants for customer-facing events, which is exactly the audience JSM emails.
- Store one row per event with the request key, service desk, actor, audience (customer or internal), notification type, and timestamp, keyed so overlapping deliveries dedupe by id.
- Retain for the window your reviews need, prune beyond it, and export as CSV on request.
The catch is that this has to run continuously from the day you start; there is no backfill, because the history does not exist anywhere to backfill from. It also has to live somewhere, which usually means infrastructure outside Jira and a conversation with security about where customer email addresses are now being stored.
A ready-made option: Notification Log for JSM
Notification Log for JSM is that pattern packaged. It records every notification-triggering event as it fires, captures the request, desk, actor, and recipient set, and keeps the log searchable by request, desk, audience, and type. Retention is a window you set, pruned automatically, and the whole log exports as audit-ready CSV in one click. It is read-only: it records and exports, and changes nothing in JSM.
Key facts
- Native log scope: failed sends only. Successful notifications leave no retained record in JSM Cloud.
- What can be observed: the Jira events that drive notifications, with their recipient sets, from the moment capture starts.
- What cannot be observed by any tenant app: final mail delivery, which happens inside Atlassian's pipeline. A log proves what was sent, not what was opened.
- Least privilege: the pattern needs service desk request read, work and user read, and app storage. Nothing is written back.
Related reading: How to audit who can access your Jira Service Management portals and how to keep Jira audit logs past the retention window.
A version of this piece also appears on Atlassian Community: read it on App Central.
Written by Abaho Katabarwa at Katabarwa Labs. We build small, single-purpose Atlassian and Azure tools that run entirely inside your own tenant. Questions: support@llmgraph.ai.