Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

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!


Custom fields and Jira Performance

How specifically do custom fields affect performance? If they are configured as being available for all projects and issue types will they be evaluated each time we view and issue even though they were never placed on the screen and hence will never have a value? Does carefully restricting the issue types and projects that a custom field is configured for mitigate performance concerns to some extent? I noticed when doing a simple api call to get an issue it does appear to evaluate all the custom fields that the issue type and project is eligible for even if the custom field is not on any screen for that particular issue.

Before reviewing our custom field setup I was hoping to get a better understanding of exactly what it is about the custom field that makes it cause performance issues. We are only at about 250 custom fields so not a huge number but would like to ensure we do not put ourselves in a bad position.

2 answers

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

2 votes
Answer accepted
Chris Solgat
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Nov 29, 2016

The short answer is, yes, every field will exist on every issue inside every project and issue type.  You can attempt to manage this through contexts and field configurations, but may end up spending more time and effort than what it's worth.  It may also have some unintended consequences if there are no Global Contexts for a field.  In my experience, it has caused problems when you want to copy/clone an issue between projects or when moving an issue between projects.

The best answer is, make a plan for when to create a new field and stick to it.  Attempting some type of Project Templates is one of the best methods I've seen.  I've seen a good rule of thumb for creating new fields is an 80/20 rule.  If 80% of the user/project base could reasonably use the new field, create it.  If it falls under the 20%, either try and come up with a different option, or get them to agree to a more "generic" field that could fall into the 80%.

There is no silver bullet to solve this, but it is very important in regards to system performance.  When Atlassian first released their performance test results, the number of custom fields was the Number 1 contributor to performance degradation.  Take it from someone working on an instance with over 300 projects, 800,000 issues and 2,000 custom fields, figure it out now, before it gets out of control.

I have a support ticket opened with Atlassian looking for a more detailed answer as to how the restrictions applied to a custom field impact JIRA indexing and JQL search speeds. Additionally, I pointed out to them that when making a REST API call (api/2/issue/{issuekey} it will return ALL fields for which that issue is eligible for. This makes me believe it is rather important to configure the custom fields such that they only pertain to the specific projects and or issue types they will be used on. Atlassian submitted JRA-63338 which leads me to believe their is in fact a problem with how the rest service functions and that how you configure your custom fields will significantly impact performance.

Like Ben Kreischer likes this

Hi there - can you please share what they gave you as an answer to your question?  I am in the same boat.  Our instance is not quite like Chris's, but it's definitely getting up there.  We have about 1200 custom fields. 

I just finished doing a massive 'clean-up' of unwanted customfieldvalue entries.  These were created from customfields given a global context and default values.  This contributed to about 4M unnecessary entries.  So for all of those that have default values, I've changed their context to be project and issuetype specific.  But I still need to figure out if this is the way to go for all other custom fields with global contexts.

Many thanks in advance!


I'm not sure if you have seen this page, but it has a little more information.  It appears that limiting the field context will make it run more efficiently. 

Limiting custom field scope

For any custom fields that can't be removed or merged safely, you can limit their scope to the context of specific projects. This helps by:

  • Reducing the index size (Jira Data Center search indexing),
  • Lowering computation complexity, and
  • Reducing the work done by other nodes in the cluster during replication.  

Like Ben Kreischer likes this

It does feel like somewhat of a trade off. Managing these custom fields via project and issue type restrictions versus the administrative overhead of doing so. 


just one point.... creating custom field with default value and global context is IMHO bad idea as every new issue is created with that default value.

I found on our instance one such text field with almost 1kb template as default value. It was Created 2 years ago, it generated 200k values, mostly default values - not seen on screens.

Imho : index can suffer with such field values, the best remedy is to find out which values are critical, migrate them to new field, narrow the scope, and delete original field. 

Before doing any change with fields, inform affected projects of course :-).