• Launch Webinar – Jira Granular Restore to eliminate Oops-moment 

    13 November 2023
    Comments are off for this post
    GitProtect webinar on Jira granular restore

    What is your biggest Jira concern? Accidental deletion of data from Jira, or data loss during migration? 

    The bigger a supporter of Jira you are, the more you know that Atlassian does not ensure you with granular, point-in-time restore in case of unintentional deletion and daily operations.

    Register to join a special launch webinar of our Partner GitProtect.io, introducing Jira Granular Restore technology on Nov 16, at 10 AM PT / 6 PM CET, and find out how to:

    • Migrate Jira data and the entire configuration from one project to another
    • Instantly restore any deleted object in Jia – projects, issues, workflows, attachments
    • Move between various Jira accounts
    • Copy project configurations from Sandbox to Production
    • Separate out projects or consolidate different Jira sites into one
    • LIVE DEMO – GitProtect Jira Backup and Granular Restore

    P.S. A dedicated webinar recording will be sent to registered people who will not be able to participate in the recording.

    Share this post

  • 8 Possible Reasons Why Your Jira Cloud is Slow

    6 November 2023
    Comments are off for this post
    Possible reasons for Jira performance issues

    Typically, the performance issue will surface as the instance gets bigger with more data.

    Some of the possible causes:

    1. incorrect/unexpected scenarios
      • 1000 Stories under 1 single Epic
      • An issue with 5000 comments
    2. design that does not scale well with larger set of data
      • an automation rule to update all the open issues in the instance
    3. very big search index
      • the time to search is correlated with the amount of data searchable
    4. automation
    5. integrations
      • external system sending thousands of REST API calls (to retrieve or update update)
    6. incompatibility across plugins
      • Individually each app works ok, but they cause issues with each other
    7. CPU intensive jobs
      • e.g. project level exports can be intensive if there are a lot of custom fields
    8. a lot of custom fields
      • By updating the custom field context, it can help to improve the performance

    The best way to improve the speed is to identify the root cause and treat the problem accordingly.

    • If it is a plugin related issue, you can try to disable the plugin to isolate the problem
    • If it is a data triggered issue, you can try to remove the data

    You can use Site Statistics for Jira Cloud to track the historical growth of issues in your Cloud instance. It can be helpful to see if the slowness is caused by huge increase of issues.

    What does Atlassian Intelligence says?

    I posed the question “Possible reasons causing Jira Cloud to be slow” and got the answer below

    1. High network latency: Slow internet connection or high network congestion can result in slower response times for Jira Cloud.
    2. Large number of issues: If your Jira project contains a large number of issues, it may impact the performance of Jira Cloud.
    3. Heavy usage: Concurrently performing resource-intensive operations such as searching, reporting, or updating a large number of issues can slow down Jira Cloud.
    4. Misconfigured plugins: In some cases, misconfigured or poorly optimized plugins can cause performance issues in Jira Cloud.
    5. Insufficient hardware resources: Inadequate server resources such as CPU, memory, or disk space can affect the performance of Jira Cloud. ❌
    6. Outdated software version: Running an outdated version of the Jira application may lead to performance degradation and compatibility issues with other components.❌

    To troubleshoot and improve the performance of your Jira Cloud instance, you can follow these steps:

    1. Check your network connectivity and ensure that you have a stable internet connection.
    2. Optimize your issue database by archiving or deleting unnecessary data to reduce database size and improve overall system performance.
    3. Review installed plugins and disable any that are not essential or causing slowdowns. Ensure that all installed plugins are up-to-date with compatible versions for your current JIRA setup.
    4. Monitor system resources (CPU, memory) on the server running JIRA to identify any bottlenecks and consider scaling up hardware if required.
    5. Regularly update your JIRA application to benefit from bug fixes and performance improvements provided by Atlassian through new releases.

    ❌ The hardware for Jira Cloud is managed by Atlassian. It is always upgraded to the latest version automatically.

    Share this post

  • Why being a Jira Admin is a Tough Job

    28 July 2022
    Comments are off for this post

    Estimated reading time: 5 minutes

    Thank you Jira Admins

    Do you know that July is the Jira Admin Appreciation Month, and 15th of July is the official Jira Admin Appreciation Day?

    As an Atlassian Solution Partner as well as a Marketplace Partner, we work closely with many Jira Admins and witnessed their passion, ingenuity and dedication on countless occasions.

    We would like to take the opportunity to share some wonderful Jira Admins we encountered

    • Kamar who worked with us to troubleshoot a mystery case on the sudden slowdown in Jira’s performance
    • Jun Xiang who set up a new service desk project all by himself, saving the money to buy an additional system
    • Hany who suggested improvements for a Marketplace app so that his team can work more effectively
    • Graeme who organised lunch and learn sessions for colleagues to share his Jira knowledge
    • Coral who stayed up until 5am so that Jira can be operational when her colleagues return to work on Monday
    • and many others who took time after work to attend Atlassian Community Events to beef up their knowledge

    What people think a Jira Admin do?

    How IT people see each other

    Going by the literal meaning, the Jira administrator is the person who administers the Jira web application.

    What a Jira Admin really do?

    However in the real life, the Jira Admins are responsible for everything that is related to Jira.
    This is a norm because many organisations do not have a team to manage Jira. Usually the Jira admin will have to wear multiple hats. More importantly, these roles also require knowledge of Jira.

    Here are some additional roles the Jira Admins are taking up:

    Jira System Engineer

    This role focuses on tasks related with systems. It requires competency in both inner workings of Jira as well as the backend systems. Some examples of the tasks are:

    • Handle Level 2 support by analysing Jira application or access logs
    • Work with Atlassian Support or App Vendors for complex cases
    • Using SQL on the database to generate reports or patch data
    • Perform Application/Server Performance Tuning
    • Perform upgrades and Disaster Recovery (DR) planning
    • Work with Security to conduct Vulnerability Assessment & Penetration Testing (VAPT)

    Jira Solution Engineer

    This role focuses on the business aspect. By providing solutions using Jira to deliver new capabilities, it increases the ROI. Some examples of the tasks are:

    • Create Jira project templates for new use cases
    • Build Jira workflows that help to improve the flow
    • Design Jira dashboards or BI reports to give visibility to the stakeholders
    • Select Marketplace apps to fulfill business requirements or improve productivity
    • Write scripts to automate some tasks
    • Or even coding Jira plugins for customised features

    Jira Coach

    This role focuses on the people aspect by helping fellow Jira users to use Jira more effectively. Some examples of the tasks are:

    • Conduct training
    • Answer questions related on the usage
    • Write KB articles on Confluence
    • Promote the use of Jira within the organisation
    • Analyse statistics to identify trends and area for improvement
    Additional roles taken up by the Jira Admins. In dedication to all the Jira Admins

    How to help your Jira Admins?

    In some scenarios, the Jira admin might even be a part-time responsibility in additional to their official job description.

    The workload will pile up until the company will engage a Solution Partner or an Atlassian Technical Account Manager for additional support.

    We have listed 9 ways to reduce the workload for your beloved Jira Admins

    1. Give up on your Jira admin rights (if you are not trained in Jira)
      • That can reduce unnecessary fire-fighting due to mistakes
      • Otherwise get proper training to be a Jira admins
    2. Look for the Jira project admins instead of the Jira admins for project permission requests
      • It can be death by a thousand paper cuts with 1 request from every user
    3. Standardize your project workflows
      • It can be messy when every project have a different workflow and different set of custom fields
    4. Raise your requests in Jira
      • That will facilitate tracking and fulfilment by the Jira Admins
    5. Use apps
      • They can automate some of the manual tasks taking up the Jira Admin’s time
    6. Use a LTS version to reduce the upgrade cadence
      • Every upgrade consumes time and effort
      • It is easier to patch an LTS version
      • It helps to minimise the turnaround time in event of a security advisory
    7. Upgrade at least once a year 
      • The risk, complexity and technical debt increases over time
    8. Host Jira behind the firewall
      • Use VPN or Zero Trust Network to access if your team are working remotely
      • That will reduce a lot of work on security
    9. Use Jira Cloud if it is suitable for your organisation
      • Atlassian will take over some of the workload

    Hopefully with more time, the Jira admins can make Jira better for everyone.

    Share this post

  • Best Practices in Jira Administration – API Tokens

    12 November 2021
    Comments are off for this post
    Best practices in Jira Administration with API Tokens

    One of Jira’s strengths is that it allows 3rd party integration via REST API calls. By providing the username, password and Base URL, it is possible to 3rd party apps to query or update Jira automatically.

    In this article, we will share why using API Tokens is a better and safer option than using Password Authentication.

    The Power of Passwords

    Besides entering passwords on the Jira login screen, it is also possible to provide the passwords on 3rd party applications or scripts to execute REST API calls.

    Some of the use cases are like

    • Create issues from Slack
    • Send alerts to Microsoft Teams
    • Update Jira issues with Commits information from GitHub
    • Integrate with your in-house systems

    If the password fails in the wrong hands, it is possible that

    • Wikileaks of your confidential data
    • Your Jira system can slow down drastically due to excessive API calls which affects the usage of other users

    Benefits of using API Tokens over Passwords

    By using API Token, it improves the security of your Jira instance

    • Safer – The API Token has a certain level of password complexity which defends against dictionary attacks
    • Isolation – It distributes the risk by having a different API token for each 3rd party integration. It is possible to revoke/reset the token for that application without any impact to other applications.
    • Differentiation – With a different mechanism, it is possible to apply more stringent checks on the usage of API Tokens (e.g. restriction by IP address range)
    • Control – It restricts ordinary users from using their credentials to do REST API calls 
    • Availability – For sites running on Single Sign On. Users will not know their passwords other than their Windows passwords
    • Validity – It is possible to set the expiry date of the token

    API Token Authentication for Jira

    We like the API Token Authentication Jira because it offers the following features:

    Disable basic authentication with user passwords

    It allows basic authentication with API Tokens. Currently, it is not possible to use the Jira Data Center’s Personal Access Token together with the username on 3rd party websites. 

    Personal Access Tokens cannot be used for Basic authentication that is commonly used by 3rd party websites

    Warning: If you disable Basic Authentication with passwords in the System Wide settings, you also can’t authenticate on non REST endpoints with API Tokens directly. You can still do that by reusing a session you got from authenticating with an API Token.

    Able to limit usage to particular IP ranges

    It is possible to limit the usage of the API token to the IP address of the internal system. You can ensure the REST API calls are coming from your trusted network.

    You can limit by ip range for API token usage

    Block requests with malicious characters in path

    This is a bonus feature which helps to defend against some attack vectors.

    Block malicious characters in path

    Limit usage of API Tokens

    It is a security best practice to grant rights only to users who needs it and has proper training. There are incidents arising from users who entered their Jira passwords on 3rd party sites or executed a buggy script.

    which users can create API tokens

    Tip: We recommend to create a group “jira-api-users” to manage those service account users who can use API Tokens.

    Set a validity of the API Token

    If the token is for testing or for temporary usage, the Jira admin can just set a shorter validity that will expire automatically. Otherwise it relies on the Jira Admins to remember to revoke the access manually.

    Service Accounts typically do not have a password validity. If the service account is from an Active Directory, there could be disruption if there is a 90 day reset password policy.

    By using the Active Directory passwords, it is possible that account is locked out of all applications after multiple wrong password attempts.

    Control over audit logging

    It offers admins a fine level of control over the information to be logged.

    What should be audit logged
    Logging of failed attempts
    audit logging of permission errors

    Share this post

  • 7 Things You need to Know about Automation for Jira

    13 July 2021
    Comments are off for this post

    Automation for Jira is one of the most popular apps on Jira. The app allows users to automate and extend Jira with no coding required. Being very user-friendly, there are a lot of admins who can dive straight into using the tool without reading the user guide. As part of our Best Practices series, we have summarised the key things you need to know in this blog post.

    For those who are new to Automation for Jira, you can check out this YouTube video below for an introduction.

    Things you need to know

    1) Asynchronous processing

    To speed up on the response time, the Automation for Jira plugin will add all updated issues into a queue. Although there are 8 background threads to process the requests, it still does not ensure the issue are processed immediately. Therefore, users will need to refresh the issue to view the changes applied by the automation rule.

    It is possible to select synchronous execution of the rule but that will have some impact in the performance.

    2) Rule Matching/Execution

    Whenever an issue is updated, the issue is matched against all the configured automation rules (global + project) . As a result, when there are a lot of automation rules, it takes time to 

    • to check against each individual automation rule
    • to execute against each matching automation rule

    Hence it is important to reduce the number of global automation rules by setting them as single project rules whenever possible. You should try to optimise the rules with more specific requirements.

    If you are seeing a lot of No Actions Performed in the rule’s audit log, then there might be chance for optimising the rule

    No actions performed could mean a waste of processing time

    3) Traceability

    The powerful app allows multiple rules to update an issue due to a single triggered event. As a result, it may not be direct to identify the problematic rule. Moreover, if multiple rules are chained together without proper planning, it could lead to “spaghetti code” scenarios which is not easy to troubleshoot.

    If the update is via workflow post functions, it would be easier to identify the bug.

    4) Performance & Runtime

    To cater to the flexibility and power of the Automation for Jira plugin, there are some tradeoffs. One of them is the processing time for automation rules is slower than post functions. For example, a simple assignment rule can take up to 3s to complete.

    Audit logs show you the duration taken for each automation

    We have encountered some rules that can take up over 10 seconds to be processed. So you should check the audit logs on the performance of the rules.

    5) Service Limits

    Not a lot of users are aware of the Service Limits which can affect the execution of the automation rules. Some of the common service limits are listed in the table below:

    There are service limits imposed to ensure the performance of the Jira

    When any of the limits is breached, the rules will be throttled until the limits are not exceeded. This could result in some unexpected behaviours as the issues are not processed during this period.

    When service limits are exceeded, throttling will happen

    The likelihood of throttling is increased when a huge number of issues are created via REST API or Test Automation plugins.

    6) Housekeeping

    The app maintains an audit log of the rule executions. Over time, the audit logs can build up which impacts your Jira database performance and clogging up your disk space. 

    You can set audit log expiry to improve the performance of your Jira system

    We have encountered some sites which the retention period is set to the default value of forever.

    It will be good to revise the retention period and set the schedule expiry during off-peak periods. For more info, check out this KB article.

    7) Integration with other apps

    Not a lot of people are aware that there are other apps which are compatible with Automation for Jira app. If you have these apps, you can use them with automation rules too.

    Best Practices

    1. Try to scope the rules within the project if possible. Use global rules only when necessary.
    2. Make sure your Jira project administrators know what they are doing. You can consider restricting the rights to trained project administrators (e.g. jira-power-admins group)
    3. Read up on Knowledge base and blog posts
    4. Conduct periodic audits. You can view performance Insights to see if there is any issues
    Performance insight gives you visibility on how the automation rules are running


    Automation for Jira is a very useful feature. However, there is a likelihood to see everything as a nail when you have a hammer in your hand. This can result in performance issues in time to come.

    We will need to understand what is the requirements and the underlying approach used by various apps. For certain scenarios, we feel it is better to use post functions with apps like

    Hopefully, with these knowledge, Jira admins can apply Automation for Jira effectively.

    Share this post

  • Best Practices in Jira – Dashboard Reporting

    9 September 2020
    Comments are off for this post
    Best practices in Dashboard Reporting for Jira


    Jira Dashboards is a very powerful feature if used correctly. In this article, we will share with you the common pitfalls as well as some best practices based on our experiences as an Atlassian Solution Partner. 

    Why people use Jira Dashboards 

    Dashboards can be from a macro perspective like % of project completion to micro level on the list of tasks with their statuses. 

    Some common use cases for Dashboards are:

    • monitor the progress of the tasks
    • track the KPIs and the health of the project
    • highlighting important stuffs (e.g. SLA breach, bottlenecks, shortages) for action taking
    • show progress to motivate the team

    More organisations are preferring dashboards over reports because of the following reasons:

    • live information – able to see the current status which is more accurate
    • time saving – there is no need for someone to spend time to compile the weekly/monthly progress reports manually
    • interactive – as compared to a chart image in a PPT/PDF
    • allows drilling in – you can zoom into the details of the issue for more information
    • self reinforcing – it encourages people to update their Jira issues regularly

    Common pitfalls and recommendations

    Security / Information Disclosure

    From our Jira consulting experiences, there are a number of instances where the dashboards and filters are accessible by users without logging in.

    Although Jira’s permission scheme will prevent public users from viewing the issues, it is still possible to disclose sensitive information which may not be meant for public eye.

    Information can be disclosed due to Jira filters shared with anyone on the web

    You should check whether there is information disclosure by logging out of Jira and visiting the URLs

    • Dashboards – https://<jira-base url>/secure/ManageFilters.jspa
    • Filters – https://<jira-base url>/secure/ConfigurePortalPages.jspa

    Unless the dashboards/filters are for public access, users should not select Public for the Add Shares option.

    Edit Jira filter screen

    Tip: There is a “Sharing with anyone on the web” in Jira configuration which you can disable to remove the Public option if your Jira instance is not for public access.

    Disable allow sharing filters/dashboards with anyone on the web

    Performance and utility

    Another common pitfall is people tends to create 1 dashboard for each project and cramp everything inside. We have seen a dashboard with over 20 gadgets added. As a result, it clutters the dashboard and is slow because it has to load a lot of information. This can also slows down the Jira instance for other users.

    From a design point of view, this is bad because it introduces a lot of noise in the dashboard. As a result, people cannot zoom into the important things that they need to take action from the dashboard.

    A well designed dashboard should fulfil the following:

    • Targeted for the role/purpose – A management report should not include the micro information like the list of tasks. Likewise a developer will be more concerned about the list of tasks he needs to work on. You can create different dashboards for different roles.
    • Incite emotion or action – it should bring attention to the readers to take any necessary action. With correct use of colours and placement, users can determine the severity easily.
    • Easy to understand – It should use the correct type of gadgets to present the information in the most direct manner. You can check out the list of Jira gadgets available on Atlassian Marketplace.
    • Responsive – it should be fast to display the information without the reader having to scroll through many screens to read the entire page.


    A dashboard is useful only when there are people using it. Another common pitfall we observed is that every user tends to build their own dashboards. While this is flexible, there are some disadvantages like:

    • duplicated effort to create and maintain the dashboards
    • decreased utility since only 1 person is using it
    • some users are unaware on the types of gadgets available that they can use for reporting
    • some users lack the proper training on how to write complex JQL queries and design good useful dashboards
    • no standards on the performance metrics to monitor within the organisation

    To tackle this, we advocate to design a set of dashboards as a template for every Jira project. When a new project is created,

    1. the set of dashboards and filters are also created based on the template
    2. The filters and dashboards are shared with the project so that people who have access to the project can access them
    3. Then the dashboards/filters are added to the Jira’s project shortcuts where all project members can access easily
    4. They can also be added to the Dashboard Folders and Menu Gadgets so that users can easily navigate to the reports
    Dashboard folders allow dashboards to be accessed directly from Jira


    Another common problem that Jira admins face is obsolete dashboards/filters. By default, only the original creators can edit their dashboards/filters.

    From Jira 7.12 onwards, it is possible to grant permissions for other team members to edit filters/dashboards. Hence a useful tip after creating a filter/dashboard will be granting permissions to the associated project roles

    • to grant view permission to all project members
    • to grant edit permission to the project administrators
    Set view and edit permissions to project roles

    Naming Convention

    We also recommend to define a naming convention for filters and dashboards. E.g <Jira project key> – <purpose>.

    This is especially helpful for users when they are searching for a filter when configuring the gadgets. For very large instances, you can find multiple filters with the same name while selecting a filter for a gadget.

    It is possible to define aliases for dashboards and filters with Dashboard Folders and Menu Gadgets.

    System Dashboard

    When a user adds a new dashboard themselves, the system dashboard will disappear.

    Actually the System Dashboard is very important because it is tedious to go through the list of project dashboards.

    The System Dashboard can complements by

    • providing a consolidated view and highlight the important things that matters to the user
    • as well as a landing point where the user can navigate to other places


    In conclusion, here is a checklist that you can use:

    1. review the list of public dashboards/filters and decide whether to disable public sharing
    2. set editing permissions for the shared dashboards
    3. define a set of dashboard templates for your Jira project
    4. define a naming convention for dashboards and filters
    5. install apps from the Marketplace that you identified that are useful

    Check out Best Practices in Jira – Dashboard Reporting (Part 2) for the continuation of the writeup.

    If you like this article, you might be interested to check out our best practices series

    Share this post

  • Best Practices in Jira Administration – Be a Jira Hero ebook

    27 May 2020
    Comments are off for this post
    Be a Jira Hero ebook

    This is an ebook on a collection of Jira best practices that Atlassian has gathered from Jira experts around the world.

    The title “Be a Jira Hero – A guide for Admins, by Admins” is well deserving. Therefore we recommend all Jira administrators and wannabes to read the 25 pages ebook.

    Jira Best Practices ebook

    The ebook is well-organised into different sections with short but clear snippets of wisdoms:

    1. How to keep Jira clean and simple for your users
    2. How to use issues effectively
    3. Best practices on managing Custom Fields and Screens
    4. Things to consider when building workflows
    5. Tips on managing backlog in Jira
    6. How to get people to work on the issues
    7. Best practices on designing the Jira dashboards for even more effective reporting
    8. Shortcuts & Hacks to work faster with Jira
    9. How to make use of automation to make life easier

    One Common Mistake

    For example, the book has highlighted in Tip #20 to incorporate Resolution into the workflows. We observed that a number of Jira admins who did not have formal training tends do not understand the concept of resolution. Consequently, they overlook this important step while creating new workflows. While the Jira appears to be working, the implications are some built-in reports may be inaccurate and an important piece of information is missing.

    Our Additional Jira Tip

    Dashboards are very useful if they are used correctly. Team members can have visibility on the progress and be reminded on the outstanding tasks. Furthermore, Management can have clear visibility without spending a lot of time preparing routine reports. As a result, users will understand the value of updating their tasks in Jira.

    Horizontal Bar Chart for Jira
    Multiple Filters Statistics Bar Chart Gadget

    Horse Shoe Gauge Gadget for Jira
    Horseshoe Gadget Jira


    To sum up, if you are a Jira administrator, you should download the ebook and review whether you have been applying the Jira best practices.

    There is no need to provide any email address to download the book. To add on, you may also want to check out the following resources:

    Share this post

  • Best Practices in Jira Administration – Jira Apps Management

    5 May 2020
    Comments are off for this post
    Best Practices in Jira Administration - Plugin Management
    Atlassian Marketplace in 2013
    Screenshot of Atlassian Marketplace in 2013

    This is a “lengthy” guide on the best practices on choosing and managing a Jira app. Coming from our years of experience as an Atlassian Solution Partner, it covers

    1. How to evaluate a Jira app
    2. How to better manage the apps installed in your Jira instance
    3. Things that Jira administrators need to watch out

    Jira Apps from Atlassian Marketplace

    By installing additional Jira apps, you can add new features to your Jira. For example, some of our popular Jira apps

    There are many more useful Jira apps available at the Atlassian Marketplace.

    Evaluating a Jira App

    Being an Atlassian Solution Partner, there are a number of criteria that we consider before recommending a Jira app to a customer. They are:

    Fit to Purpose

    The app should be able to address the requirements fully. It should be easy to use. The additional feature should not cause confusion to the existing users. We will also assess their design is robust and does not conflict other plugins or use cases.

    Atlassian Marketplace Listing

    Best Practices on Multiple Filters Chart Gadgets Marketplace Listing

    It is very important to check out the app listing on Atlassian Marketplace. It contains a lot of useful informations like

    • Rating and Reviews
    • Number of Active Installations
    • Vendor Accreditation
    • Compatibility with the latest version of Jira
    • Support

    Rating and Reviews

    While the rating and reviews do not mean much for a newly listed app, they do give insight of poor services or badly designed apps. Typically, users will flag out any issues that require attention. So, if there are no negative reviews, it is safe. And if there are a number of good reviews, then it is very safe.

    Number of Active Installations

    If an app is popular with a significant number of active installations, that is a good sign that the app is useful and functioning without major issues.

    Vendor Accreditation

    Atlassian has a Top Vendor program who has met the following requirements

    • App traction – Their paid apps must attain at least 500 active installations
    • Timely support – Has a Service Level Agreement (SLAs) and committed to provide at support for their users
    • Support Website – Customers can raise support request easily via a website or email when necessary
    • Vendor reliability – Atlassian conduct checks periodically to ensure they offer great customer experiences

    For those exceptionally good ones, they are further recognised as Gold/Platinum Top Vendor.

    Versions compatibility

    If the app is only compatible with an older version of Jira, that is a big warning. You do not want to be left dangling helplessly for your next Jira upgrade.


    Some apps are explicitly marked as unsupported. Unless you can accept the risks, it is better to avoid them.

    Data Center Approved

    Data Center approved apps are those that have passed Atlassian’s stringent criteria for use in Jira Data Center environments. As it takes considerable effort to become a Data Center Approved App. vendors will usually do that for their established apps. Therefore this is a plus point.

    Thorough Documentation

    Although some users will usually dive in without reading the user guide, it helps when the documentation contains

    • A quick overview of the functionalities
    • Comprehensive writeup and how to use
    • FAQs to facilitate on-boarding and best practices
    • Up-to-date release notes
    • An easy to navigate structure

    Unless the app is really simple or open source, it is a risk to install an app with a one pager documentation.


    Last but not least, the pricing of the app is also an important consideration. The app should have a reasonable pricing so that you will be assured of support for long term. It is also possible that you will upgrade to higher user tier or Data Center as Jira becomes an enterprise application. Hence the pricing for higher tiers should not exceed your budget.

    For free apps, they should be from a credible publisher with significant number of installations. Otherwise, the publisher may withdraw support in near future.

    Before Installing an App

    Downloading the compatible version

    There is a common mistake for Jira administrators who are unable to download the app via the Atlassian Universal Plugin Manager. The default download link on the Marketplace listing is for the latest version of Jira.

    If you are not using the latest version of Jira, the correct steps to install/upgrade the app will be

    1. Click on the Versions tab
    2. Select See all … versions
    3. Hover on the topmost version which matches your Jira version
    4. Click on the Download link
    5. Upload the file via Atlassian Universal Plugin Manager in Jira


    It is a best practice to install the Jira app on a Test environment first. It is not advisable to install an app directly onto the Production environment. This is because some apps may make changes to the database. Some changes are not be reversible when you uninstall the app later.

    Maintaining a Change Log for the Apps

    We usually advise our customers to create a Confluence page to track on the app installations, upgrades and uninstallation. This best practice helps to keep all the related information organised neatly on a single page.

    The change log table can include the following information

    1. Date of Change
    2. Changed By
    3. Name of App
    4. Action Performed (e.g. install/upgrade/uninstall)
    5. From Version
    6. To Version
    7. Jira Issue Key
    8. Additional Notes

    This will be useful especially when there are multiple Jira administrators who can perform changes. Although the audit log has a record of the changes, the default data retention period is only 90 days. It is also not that easier to read.

    By using a Change Log, the administrator can link the change with a Jira issue and add notes. The Jira request helps to identify the user who raised the request to install the app together with the background context.

    When there is an incident, the App Change Log will be useful to identify issues caused by app changes.

    Things to watch out

    It is not the end of the story after installing the app. There are a few useful tips for Jira administrators to watch out.

    Hardware Sizing

    With more apps installed, it is likely that the memory footprint might increase over time. It will a best practice to check on the JVM memory utilisation from the System Information page after people start using the features. Likewise, CPU usage monitoring is also a best practice.

    Expiring Licenses

    There are a handful of apps which will stop working without an active license. So be sure to renew your licenses before they expire to gain access to support and newer releases.

    Being informed

    You can click on the Watch app link on the Marketplace listing. By doing so, Atlassian Marketplace will send you an email whenever there is a new version released.

    Upgrading the Apps

    As a best practice, it is important to upgrade regularly to get newer features, performance improvements and bug fixes. For security vulnerabilities, you should upgrade as soon as possible once you received a security advisory.

    Scheduling Upgrades

    Although there is no need to schedule a maintenance downtime for installing/upgrading Jira apps, it is a best practice to do that during off-peak periods. During an app installation, there is a short interval where the Atlassian Universal Plugin Manager removes the old version and installs the newer version. You do not want any critical operations in between that period.

    Also some apps may execute jobs during the upgrade to do some data crunching to support a new feature. Therefore, please read the release/upgrade notes for the app before you click on the upgrade button in Jira.

    Share this post