Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Jira Watcher Field and Jira Component Watchers

Early this morning we upgraded our Jira test environment from version 8.20.1 to 8.22.2, and quickly learned that the apps Jira Component Watchers and Jira Watcher Field not only do not work with the new version, they completely break Jira if they are enabled (reindexing fails, no dashboards, no filters). As the vendor has discontinued them, we no longer have any options for adding and managing watchers on our Jira issues.

We have many thousands of issues created using watchers and component watchers. This puts a major snag in my migration plans. Questions for Atlassian and the community:

  1. Do alternative apps exist that provide the same functionality in Cloud? And are they free?
  2. If no alternative apps exist, how can I upgrade my local Jira Software and still maintain that functionality? Has anyone deveoped a workaround?
  3. What impact will this have when I try to migrate my data from our on-prem server to the cloud?


2 answers

1 accepted

4 votes
Answer accepted

This is only in reference to Jira Watcher Field app. I am by no means an expert on it, but I have deprecated it for a few clients moving to Cloud. Might want to wait for others to chime in before taking my word, but figured I'd get the ball rolling.



As far as I know, the watcher field simply made things easier. Watcher management is built-in to Jira natively. The field simply gave you a different UI, but they all get added as Jira watchers. Dropping the field will not remove existing watchers. (Someone, please, correct me if I am wrong!)

To manage watchers natively, on Server, click the number next to Watchers:


Assuming you have relevant permissions (Server Permissions), this will open a dialog listing the existing watchers and provide an input to add additional watchers. If you hover over an existing watcher, their row will highlight and a trash can icon will show - allowing you to remove the watcher.

The only missing feature that I am aware of is the ability to add watchers from the create screen. The simple work-around is to add them after clicking Create. If that is too much trouble or does not fit with your processes, you can check out this KB article: How to add Watchers or Request Participants during issue creation. Additionally, Scriptrunner and other add-ons can solve this, to an extent, even in Cloud.

If you are adding static watchers on Create, you can use Automation for this (mainly referring to Cloud on this one). Also for static watchers, if you only care about emails (and not the Watchers UI), use Notification Schemes.

On Cloud, to manage watchers you can follow this: Watch, share, and comment on an issue

EDIT: Fixed cloud watcher link.

0 votes

@Michael Thompson -

Just to clarify that you upgraded your on-prems version (server/data center) to 8.22.2 right?  In addition, Watchers and components fields are native to Jira software - What was your functional needs to acquire those add-ons for handle those fields?

During version upgrade, all add-ons should have been evaluated to ensure that they support the newer version of Jira Software prior to the upgrade.  Typically, it is each 3rd party vendor that need to address the issues.

In regards to Cloud env, if you can provide what you are your needs for those apps, then we may be able to advise further.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

Hi Joseph,

Yes, we upgraded our on-prem test Jira Server from 8.20.1 to 8.22.2. We had those add-ons many year before I joined the company, but the purpose is to ensure that the proper team members, engineers, and/or managers are notified of new, updated, or closed Jira issues.

We did you an evaluation, but these two and four others were listed as "unknown" after the upgrade, so it was a gamble. The other four work fine. Also of note, when we upgraded from 8.16 to 8.20.1 back in the fall, they were also listed as "unknown" but worked fine, so we believed they would work this time as wel.

Our needs in Cloud remain the same as now -- to ensure the correct people are always notified of Jira issues.

@Michael Thompson 

Out of the box, Jira project's notification scheme already provide the notifications to reporters/watchers/assignees by default against different issue events (This is the same for both Server and Cloud envs)

In addition, in the 8.2x versions, you can utilize Automation for Jira (vendor is Atlassian) to configure rules to send custom notifications to users based on triggering conditions - 

For the server env, you will have to purchase the add-on from the marketplace -  However, this add-on is a out-of-box component for the Cloud env.

Here are the documentations for your references -

Server -

Cloud -

Since I don't know more about your previous add-ons (in question) assuming those add-ons didn't created any add-on specific custom fields/embedded backend routines in your Jira env for issues , then if all you want to do is to achieve/maintain the notification handling goal, then you can consider my aforementioned recommendations.

Lastly, it is always a risk when dealing with 3rd party add-ons of "Unknown" status when one upgrades the Jira envs.  It is always the best to disable/uninstall them prior to upgrades in a non-Prod env first to assess the impacts to your organization.

Best, Joseph

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events