Jira Software guardrails
The content of this page applies to Jira 9.17. If you're looking for information about a different version, select it from the menu in the top-right corner.
Background
We’re committed to supporting the needs of our largest customers, and this includes continually improving the performance and scalability of our products. The amount of data in your instance can be a factor in performance and stability problems. As your instance grows, so does your risk of performance degradation over time. Often this is a gradual degradation and can go unnoticed until you reach a point where it has a significant impact on your team.
In the table below, we’ve described the performance and stability impacts that we’ve observed and suggested some actions you can take to reduce your risk. The guardrails are based on real-world experiences with some of our largest customers, but won’t necessarily be representative of every organization’s experience.
Ways you can reduce the risk of experiencing serious performance and stability problems may include:
application changes, such as upgrading to a newer application version to get the benefit of performance improvements, or changing the way users are managed.
infrastructure changes, such as increasing memory, CPU, or running a cluster or mirrors.
data cleanup activities to reduce your footprint, such as archiving or breaking up monolith sites.
It’s important to note that these aren’t hard limits, and some of your product instances may already exceed these thresholds. There are a number of factors, including the interplay between different data types, and site load, which will influence whether you experience the potential impacts listed below, and to what degree. As with any type of risk, it’s essential to identify the risk and make a plan, so you can prioritize those actions that will help you reduce the probability of future performance problems.
Definition
Product Guardrails are data type recommendations designed to help you identify potential risks and aid you making decisions about next steps in your instance optimization journey.
Jira Software guardrails
The following guardrails are provided to help you identify and mitigate scale risks, and make decisions about cleaning up your instance.
Projects
Content type | Number of active projects |
---|---|
Guardrail | 7000 projects (not archived) |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Comments
Content type | Number of comments per issue |
---|---|
Guardrail | 1000 comments per issue |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Attachments
Content type | Number of attachments per issue |
---|---|
Guardrail | 3000 attachments per issue 10MB per single attachment |
How to find this number | How to find issues with the most attachments in the database |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Issue links
Content type | Number of issue links or sub-issues |
---|---|
Guardrail | 1000 issue links |
How to find this number | How to find issues with the most issue links in the database |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Text
Content type | Amount of text in a field. |
---|---|
Guardrail | 255 characters in single-line fields 100k characters in description and multi-line fields |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Custom fields
Content type | Total number of custom fields |
---|---|
Guardrail | 1,200 custom fields |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Epics
Content type | Number of epics |
---|---|
Guardrail | 120,000 epics |
How to find this number | You can use JQL to identify the number of epics, |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Sprints
Content type | Total number of sprints |
---|---|
Guardrail | 60,000 sprints |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Workflow scheme bulk actions
Action | Associating a new issue type to an existing workflow scheme |
---|---|
Guardrail | 1000 issues per bulk action |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Change history
Content type | Number of changeitems or changegroups associated with an issue |
---|---|
Guardrail | 20,000 changeitems or changegroups |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Users
Content type | Total number of users synchronized between LDAP and Jira |
---|---|
Guardrail | 100,000 users |
How to find this number | |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Groups
Content type | Total number of groups synchronized between LDAP and Jira |
---|---|
Guardrail | 25,000 groups |
How to find this number | How to get the total number of groups |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Depth of nested groups
Content type | Number of levels of hierarchy when groups are nested |
---|---|
Guardrail | 4 levels deep We also recommend groups do not contain a mix of users and other groups, as this can have a negative impact on performance. |
How to find this number | How to check the depth of group nesting |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options | Try rebuilding your group structure to prevent deep nesting. For example, you can split your group structure into two categories:
Nested groups come with their own set of limitations and potential side effects. Make sure that you understand this mechanism before rebuilding your group structure. For more information, see Managing nested groups. |
Automation for Jira
Automation for Jira guardrails is the derivative of the general health of the instance. When assessing the performance of rule executions, keep in mind the performance and scaling guardrails for Jira Software and Jira Service Management.
Learn more about the best practices for optimizing automation rules
Create/Update/Delete rule
Content type | How often rules are created/updated/deleted |
---|---|
Guardrail | Instance with:
|
How to find this number | Requires access to the database Replace the X with the corresponding minute value. Adjust the singular/plural ending of the time unit in a query (only for PostgreSQL).
|
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Automation rule executions
Content type | The number of daily rule executions |
---|---|
Guardrail | 10,000,000 |
How to find this number | Requires access to the database
From the UI (aggregated per rule) To find a number of daily rule executions:
|
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
Learn more about Jira Data Center automation release notes Find out more about Automation for Jira version compatibility: |
Rules with JQL
If the rule contains the JQL search we should assess if it won’t cause performance issues.
Content type | The complexity of JQL queries |
---|---|
Guardrail | Must be assessed individually (per rule) |
How to find this number | App Diagnostics JQL monitors are available under Learn more about Jira Data Center monitoring Slow JQL log Records JQL queries and their sources for executions exceeding the default threshold of 400ms: Threads related to Automation for Jira will have the following prefix: |
Risks | We've observed these problems when operating above this guardrail:
|
Mitigation options |
|
Automation for Jira monitoring
Automation for Jira has a set of monitoring tools available.
Learn more about how to monitor automation activity and diagnose issues
For large-scale instances, it’s highly recommended to:
- Shorten the log expiry time. In large instances, audit logs can build up over time, impacting your Jira database performance and clogging up your disk space. Our guide about expiring audit log items explains how you can regularly delete those old audit log items you no longer need.
- Adjust the service limits. Jira automation includes a set of service limits to keep your automation rules in check. When rules breach these limits, they're throttled and disabled so they don't affect your Jira instance.