We make one of the apps on this page, so read it with that in mind. Everything stated here is taken from the public Marketplace listings and can be verified in about a minute. Where a competitor is the better choice, we say so.
Jira records every change to an issue description. It records nothing when a comment is edited: the previous text is overwritten and gone. The same applies to deleted comments.
This has been requested since 2007 in JRACLOUD-12400, with 547 votes and 69 linked support tickets. In August 2024 Atlassian closed it as Won't Fix. Jira will not do this natively, so an app is the only route.
| Loggard Comment Audit Trail |
codefortynine Comment History Log |
SaaSJet Issue History |
|
|---|---|---|---|
| What it covers | Comments only | Comments only | Full issue history; comments are one feature |
| Permissions requested | 2 | 7 | See listing |
| Write permissions | 0 | 2 | See listing |
| Architecture | Atlassian Forge only | Forge with Connect modules | Connect |
| Up to 10 users | Free | Free | Free |
| 50 users / year | $300 | $335 | $750 |
| 100 users / year | $600 | $670 | $1,500 |
| 200 users / year | $1,200 | $1,170 | $2,700 |
Price is not the interesting column. Loggard and codefortynine are within roughly ten percent of each other, and above 200 users codefortynine is slightly cheaper. If cost is your only criterion, the difference will not decide anything.
An app's requested permissions are published on its Marketplace listing, before you install it. For an audit tool they matter more than usual, because an audit trail that can be altered is not an audit trail.
read:jira-work — required by the Forge platform to receive comment events. Atlassian offers no narrower scope for these events.
storage:app — to store the recorded versions in Forge storage.
Neither grants write or delete access. The app is technically incapable of creating, modifying or removing anything in Jira. It exposes no function to alter or delete a stored record — not for a site administrator, and not for us.
read:jira-work, read:jira-user, read:connect-jira, read:app-system-token, storage:app, write:connect-jira, write:issue.property:jira
Two of those are write permissions. We are not suggesting they are misused — established vendors request write access for legitimate implementation reasons. The point is narrower: if your reason for installing an audit tool is that something has to be tamper-evident, the size of the permission set is part of what you are evaluating.
You do not have to take our word for any of this. Open either listing on the Marketplace, scroll to the permissions section, and count.
Loggard is built entirely on Atlassian Forge and makes no outbound network calls of any kind. There is no Loggard server, no database and no third-party service; nothing is sent to us, and there is no analytics or logging provider involved. Records are held in Forge hosted storage, encrypted at rest by Atlassian and covered by Forge data residency.
Apps built with Connect modules run part of their functionality on vendor-operated infrastructure. That is a normal and well-established model — it is simply a different answer to the question "where does our comment text end up", and worth asking if you are in a regulated sector.
Loggard restricts the history panel to users holding the Edit All Comments permission in that project. Everyone else sees a note saying the history exists but is not available to them.
This is deliberate, and it is a trade-off rather than a pure advantage. An audit trail that everybody can read is a second copy of text someone may have had a legitimate reason to correct. If you want the history visible to your whole team, Loggard is the wrong choice.
All three apps share the same fundamental limit: they record from the moment they are installed. Whichever you choose, installing it sooner is worth more than choosing perfectly.
That last one is the question most buyers forget to ask, and it is the one that decides whether the record would survive being inconvenient.