@Dave, I believe you forgot to mention in your comment the suggestion for point #12 in the original description:

"Audit logs does not show changes made by Add-ons. Example custom fields created on addition of TEMPO does not log into Jira audit logs"

This point #12 was added just recently, as result of support ticket JST-895119, and has resulted also in creation of the following suggestion: https://jira.atlassian.com/browse/JRACLOUD-81508.

I request to make sure that suggestion JRACLOUD-81508. is also mentioned here in the new description and linked to here.

This is a critical missing functionality.

The customers are relying on the Jira audit log to reflect the main admin changes done by anybody, including apps. Unfortunately, the audit log simply doesn’t show anything done by the apps.

This is a huge concern for our customer! And this makes it very hard for them to approve apps for usage. They simply cannot accept the risk of an app that has Jira admin permission, that can do everything in Jira, without ability to monitor it.

@Jason - Actually, it's probably better to have a newer date on tickets describing the remaining issues. Here's why: when you have a ticket that's 20 years old, it's hard to know how many of the people who originally voted or commented on the issue still care about it. You don't know how many of those users are still using the product, how many found a different way to address the requirement, or if the issue's been resolved in some other fashion. In short, you have to spend a lot of time figuring out what's still relevant and what's not.

With a new issue containing new votes, watchers, and comments, you don't have to waste time on all that. You know which people care about the issue and can be reasonably certain the comments are pertinent.

This issue has been opened for nearly 20 years! And now, after all that time, it is not resolved and Atlassian decides to split it up into multiple issues.

In fairness to the original user who reported this issue, all those new cases ought to have the same Created data of 16th February 2004 as well. That way the metrics on Atlassian's dashboard for tracking case lifecycles and closure times will reflect the true length of time that these have languished without getting the proper attention for what, in an increasingly cybersecurity and audit-aware business environment represent "base level" functionality that every modern product should have "baked in" from Day 1.

And if the number of Votes and Watchers of those new issues is small, then Atlassian will inevitably fail to implement solutions because of a perceived "lack of user interest"

Sheesh!

We are closing this ticket (JRACLOUD-3157) in favour of more specific feature requests.

Hi everyone,

Firstly, thank you for all the feedback you have provided on this ticket, JRACLOUD-3157 Jira Administration Audit trail / notifications. We understand the time and effort it takes to give such feedback and want you to know your contributions are appreciated.

We are listening and want to improve audit logging. In order to get better fidelity on the types of audit logs we need most, we have split this suggestion into more specific tickets which are listed below. If you raised a support ticket about this problem and were linked to the issue, we have relinked your Support ticket to one of the most relevant features listed below.

We recognise the demand for better audit logs that this issue represents, and breaking this ticket up into smaller, disparate issues will give us the best means of addressing the many individual concerns that have been raised here.

If you have previously voted for JRACLOUD-3157 we encourage you to take the time to look through and voting for tickets listed in the Issue Links on the following tickets:

• JRACLOUD-79986 - Tracking site-level audit log feature requests
• JRACLOUD-79984 - Tracking Organisation-level audit log feature requests

This will help us understand demand and where to focus our development efforts.
 

Request from the original description	Current status
A user is created, but we dont know by who. Sometimes, we see a user that isnt meant to exist e.g. "testUser" - but we dont know who to contact to get rid of it. Sometimes the user themselves have a problem logging on, getting access to their project etc - and it would be useful for them to contact the administrator that created their account rather - therefore it would be useful to have this info in an audit trail, so we can find out who it is - or better still, have this information in the email sent out (JRA-2555)	This is now tracked as a bug, here: JRACLOUD-80541 In site-level audit logs some actions are attributed to Author : JIRA despite having been enacted by a user
A default notification scheme is changed - affecting all projects - and we dont know who did it (we want to know who did it so we can ask them not to do that again)	this audit log now exists.
A global custom field is added (usually by mistake) - affecting all projects - and we dont know who did it (We want to know who did it so we can remove it - and ask them not to do that again)  (done)	this audit log now exists.   Note if an existing custom field is added to a screen that will not shown in the audit log. The feature request for this can be voted for here JRACLOUD-67246 - Screen and screen scheme changes - Audit log feature request
A new issue type is added - affecting all projects - and we dont know who did it (we want to know who did it so we can discuss using an existing issue type - or discuss the addition of a new type so that it makes sense to more projects)	The feature request is now tracked here JRACLOUD-61853 Audit log should register Issue Type and Issue Type Scheme
A user we dont know about is given jira-administrator priveledges. Given the fact that this new user may not know very much about how to administer Jira - and they can go on to do the things mentioned above, then we need to know about this. We need to contact the administrator who did it and ask them not to do it again. We need to contact the new jira-administrator and make sure they know what they are doing!	this audit log now exists.
Someone turns unnassigned issues "on" and all of a sudden Project Leads stop getting notifications for new issues on their project. We need to know who did it, so we can break their legs .	The feature request is now tracked here JRACLOUD-75647 Log "General Configuration" changes in the audit log
Currently, the Audit Logs of Jira doesn't cover "Time Tracking" Global Settings changes. Such as Site-Admin changes the format from Hours to Days. This is not recorded in the Audit logs and all of a sudden the Jira Issue's Time Tracking fields change the way they show Original Estimates, Time Tracking, etc.	The feature request is now tracked here JRACLOUD-67246 - Screen and screen scheme changes - Audit log feature request For changes in the Time tracking provider, you can refer to JRACLOUD-8328
Currently, the Audit Logs of Jira doesn't cover "Time Tracking" Global Settings changes. Such as Site-Admin changes the format from Hours to Days. This is not recorded in the Audit logs and all of a sudden the Jira Issue's Time Tracking fields change the way they show Original Estimates, Time Tracking, etc.	I believe this request is now obsolete. Time format is now set at user-level. The format is controlled by the Language set here: <your site name>.atlassian.net/secure/ViewPersonalSettings.jspa   More information on this feature can be found in the Description of this post.   A feature request to change this functionality may be found here JRACLOUD-76814 – Allow further customization for date and date/time field (that's not limited to locale)
There is no Audit log for the changes to Default "Priority" on the Global Priority Settings. An Admin can change the Default Priority from Medium to Low and the next created Issues take that priority by default.	The feature request is now tracked here JRACLOUD-78430 Adding, reordering or removing priority does not log an entry in audit log
Audit log doesn't capture "Issue Collectors" that are deleted from JIRA Projects	The feature request is now tracked here JRACLOUD-81339 - Creation, edit and deletion of issue collectors - audit logs feature request
Currently, the Audit Logs of Jira doesn't cover changes made to the filter. Creating multiple filters, changing the filter owner and modifying filters in the Jira Software. None of these activities is reflected in the audit log	The feature request is now tracked here JRACLOUD-75028 Display more data on audit log about filter condition changes

This feature is greatly needed.  Thank you for considering.

+1

This issue is only 19 years old - created on 16/Feb/2004 10:05 PM.

Should Jira address it when its 2 decades later? For shame.. for shame...

Ah yes, gathering interest on another basic feature - security this time.

This is, not only important but critical for any serious ISO-like certification. What it's the sense of tracking a change like creating a user, with when, what, how was created, but not by who?

Got redirected to here from a support request.

I was looking to identify who deleted a set of issues in a project and to my surprise that is not available in the audit log. After raising a support request, i was directed here but when reading this it seems we are in a dead-end.
This is a granular tool for Jira administrators and really needs a lot of attention/improvement. 

+1 just migrated from DC to Cloud and had something go amiss that doesn't appear to be logged in the events (support case MOVE-114714)
Pretty blown away by the fact this hasn't been taken seriously for years as being able to audit changes to critical elements is usually considered pretty vital on most other platforms...

Stumbled on this because the audit log still doesn't show who added a user to Jira and/or added users to groups & on raising a support ticket we've been directed here. This is obviously bad given that this is actually a place where we really, really care about who the author of an action is.

This is especially a problem for us given that we a German company with a need to follow a lot of data privacy regulations and therefore need to be able to both restrict access to relevant information and see who granted someone access to relevant information.

However both issues I could find related to this problem (https://jira.atlassian.com/browse/JRACLOUD-66723, https://jira.atlassian.com/browse/ID-57\) appear to be closed - but the problem is still there. This is also evidenced by some comments from 2022 on the linked issues.

This is also clearly a known issue for Atlassian, since Atlassians own documentation on audit logs states:

> There's a known issue which prevents the Author field from displaying the username for changes that were made in the user management pages in Jira cloud products (including changes to users, groups, and application access). For example, events like users being created or assigned to groups won't include the username of the user who made the change.

Bump, it's a bit weird considering this is possible for Confluence Cloud and not Jira Cloud.. You would think it would be the other way around!

this is a critical item for us.

Bump.

Please implement better audit logging.  Changes at a global level should not be 'missed' events.

Another case of loss of functionality compared to the server version
In server we have perfect audit regarding Filters. Here is absolutely nothing, zero.
Cloud should be cheaper each time we missed something that is in version we are migrating from.

Since moving to Cloud three weeks ago this is the fourth or fifth time the support team has said "it looks like you are running into an existing bug/feature request, please go vote and watch it so you will know when it is fixed" and each time it is a bug that is ancient and has hundreds of votes. This last time the support person pre-apologiezed that this was a useless endeavor.

The bigger joke is that for this issue:

1. Currently, in the audit logs of JIRA, it does not cover changes done in the screen scheme section, or screens in JIRA Administration. We are then unable to find out who performed changes there.

Atlassian themselves can't even figure it out. So we had a major screen get changed, we interviewed every single person (in the very small group of people who could make the change) and none of them said they were doing any admin stuff at the time we thought it had occurred. 

So we have no idea if there is a major fundamental bug in the cloud system (screens configs randomly changing) or if someone did an accident....

Atlassian made itself into de-facto monopoly in the field. 

Monopolies be like monopolies and the only thing they react to is the money drain. As far as you are not prepared to vote with your money, this won't change.

How can this have over 800 votes and over 550 watchers and still be "gathering interest" ?

Seriously Atlassian, it's time you started listening to the "voice of the customer"

My suggestion to everyone who reads this comment is to spam all of Atlassian's social media channels and in places like LinkedIn whenever they comment on other people's posts (e.g. a new Atlassian employee), with a "well maybe you could fix JRACLOUD-3157" comment.

Let's see if a but of public pressure is enough to get them to change their ways...

Failing that, we need to encourage all our users (not just us Admins) to boost the vote count significantly. What are Atlassian going to do if this issue gets 20,000 or more votes? They can only dodge their responsibilities for so long!

Not being able to see who added a user to one of the admin-granting groups is a significant issue that continues to come up during our IT Controls reviews

+ 1

It's hard to believe that there has to be a discussion on whether or not to include audit activity on who added or deleted a user, but here I am, adding a comment saying that this should be a thing.

For most of the events we see Author as "JIRA" ,example events like user added, how do we supposed to track who is Jira?

Please improve those logs. Every national regulation authority will rip you apart, if you can't tell what happened to some of the information on your platform or in your ticket system.

The ability to identify which admin added or removed a user you'd think wouldn't be too much to ask? 

The ability to know which site-admin has a user created, ist important for us. How can we do it?

The ability to see who changes time tracking settings is important for us, because it is easy to do as Tempo admin from Tempo inerface, while not being a site admin

Hi - need some growth on the already-amazing audit log please. Example, auditing changes to priorities. Changes to default assignee of project. automation rules general management. etc. Thank you

It should be a basic privilege to see who created the user by other admins.

unbelievable that there is no way to provide such a simple thing ...

@Dave Meyer- So if I understand correctly, if I want to know who added a user to Jira, I have to pay another $3/user/month for the privilege???

I create a ticket via email.
The settings are set to "Customers added by agents and admins".
Sometimes the emails I need are rejected.
I want slack to notify me when an email is rejected.

++ Voting and following this request. Specifically item 7 around adding screen changes to the Audit log

Thanks Dave,

But it doesn't help the administrator who is a site-admin, but requires org admin rights to view an audit log.

Kind Regards

Lisa

Hi @Dave Meyer

Lisa has a point. This ticket has been opened for over 17 years. Why not start a fresh "umbrella" ticket and link in all the current tickets related to gaps in the audit logging capabilities. Clearly people are still feeling pain about this after all these years. Many of the requests are reasonable ones - administrators need to know when other administrators actions introduce (potentially breaking) changes to their Jira environment, and where those changes are applied so that they can be undone. Without that audit trail, an administrator is forced to manually re-examine everything page-by-page to figure out what happened, which is unnecessarily painful.

As an Atlassian suite user (Jira, Confluence, Bitbucket), it is really frustrating, and more than a little disappointing to get the standard "it's on our roadmap" or "it's not yet on our roadmap" or "we're closing this issue because of a lack of interest" answers.  Atlassian bills itself and its products as world-changing ones that can delight customers and allow them to deliver higher quality products with less time/effort, yet it seems that doesn't apply to its own products where customer tickets languish for years without ever getting any action that would result in a product change.

Hi 99db9a14759e,

Audit logs for the following activities are available in the Atlassian Access audit log. Since actions like adding or removing users are taken by site administrators outside of the context for a single product (for example, you can deactivate a user and implicitly remove their access to all products) they are not included in the Jira product audit log.

• Site & product users: Actions that admins complete for users with product access, typically from the Users page or an individual user’s details page. (like inviting a user to a product)
• Groups: Actions that admins complete, typically from the Groups or Product access pages. (like changing which groups have access to a product)
• Organization: Actions that organization admins complete, related to settings or other organization pages. (like giving a new user organization admin privileges)
• Security policies: Actions that organization admins take related to the organization’s security policies. (like enabling SAML SSO)
• User accounts: Actions that the organization's administrators take on their managed accounts. (like permanently deleting a user's account)

Regards,
Dave

Created 16/Feb/2004 - can we get an ETA on this?  Currently I cannot see who added or removed a user.  That should be basic functionality.

As explained in ticket:  PCS-34104 we need to know, for next gen projects, when a field is created, in which project it was created. We had an incident because a field was created in a next gen project with the same name of an existing custom fields (filters and Dashboards were broken) and due to the lack of info in the audit log it was not very easy to find the solution of the incident (fortunately we were able to contact the user who worked on the next gen project and we were able to remove that field to make everything working ok again). This is also related to: JRACLOUD-61376

I raised a issue through Atlassian Support about Confluence and they opened https://jira.atlassian.com/browse/CONFCLOUD-72021

It seems like it should be linked here too (and vice versa).

How many more votes does this issue need to get some action? It's already over 600!

https://getsupport.atlassian.com/browse/PCS-31107

Good Day

Is there an audit system or log for the tasks?  If I edit the description of task, add points, remove them, etc.... where can I view that in the form of a time stamped record?

Thanks

Proper accountability for operations should be a must have, as makes the tool feel more reliable. While I understand that increasing the variety of operations for the Jira Audit Log may make it unwieldy, I see little reason to not split them into specialized ones. We have been disappointed on a couple ocasions where not even the support team can track specific operations because they are not captured anywhere. I know there's a case to make on rights configuration, but without this tracking there's no way to determine where responsibility lies.

Olá boa tarde!
Ultimamente estou tendo a necessidade de verificar o registro de loguin no sistema Gira Cloud, para ver a hora que meu colaborador esta logado ou não.
Porém não estou encontrando tal solução, espero que em breve este recurso esteja disponível na plataforma.

What changed in the workflow audit log it will be very useful to audit.

We have a lot of projects and we use groups to give people access. There's someone who creates users and doesn't assign groups - and then I get calls from Eastern Europe at 2am because people can't access what they need. PLEASE I need to be able to see who created a user. 

mike.otto1, As written in the latest status update on this ticket, most of the requested audit logs are already available (part in Jira Settings, part in the Organization Administration panel):

For Jira Cloud, we have implemented a number of the audit log requests on the original description, including notification schemes and custom fields. ...

Please review below documentation for details:

• Auditing in Jira applications
• Audit logging

Just another comment to say this is a really important feature I'd love to have.

Please tell me this request wasn't actually created in 2004. 
566 votes and still gathering interest...

This came up again for me today, as a site admin who's not on our tools team (there are a few) changed the self-signup setting to On.  Luckily we caught it quickly, but unless someone confesses, I have no way to know how it happened so that I can reach out with training (or a stick).

Adding yet another vote to the pretty basic request for audit logging.  

Hi everyone,

For Jira Cloud, we have implemented a number of the audit log requests on the original description, including notification schemes and custom fields. While adding additional Jira-specific events to the Jira audit log is not on our roadmap, we will keep this ticket open to announce if new events are added in the future.

For our cloud products broadly, we are working to add a richer set of audit logs to Atlassian Access in order to provide better visibility into administration activities across all of our cloud products. We are focused on addressing ACCESS-577, and then expanding into additional insights into Atlassian account changes, app installations, site and billing changes across all the products in use at your organization.

Regards,
Dave Meyer
Atlassian Product Management

When setting up the system, we decided not to issue generic/shared logins for auditing purposes.  Now that we're in need of the audit log since someone keeps assigning people to the wrong security group (BIG COMPLIANCE ISSUE), I discover the log is USELESS!  Stamping the log with "Jira" because the action was performed by a site-admin makes no sense.  I know a site-admin is doing it.  I need to know WHO IS DOING IT.

Will have to meet with Internal Audit to determine if we need to pursue a different system.  Security for SOX-compliance in the United States is a MAJOR issue.

(BTW-I find it ironic that my simple, unimportant comment here is stamped by my name/login ID, whereas the creation of users or changing of security permissions is given a generic, meaningless stamp.  The irony is just too thick...)

Our users recently had many issues go 'missing' although the test cases for these issues are still present.  Having these audit logs would help the team to understand what happened and take the necessary course to resolve the issue as well as provide appropriate training.

We recently had a case where someone accidentally changed global status names, which affected all projects.  This is not audited anywhere and made it very difficult to track down what happened and who to work with to resolve the issue.  All administrative actions should have an audit trail of who made the action and when!

I too favor raising the priority of this feature.

If there is a fear of cluttering the result of "Audit log", then the product team may think of providing another link such as "Secondary audit logs" (or may be  a different name) which reports the events the posters are interested in.

Regards