Configure safeguards

As your Jira instance grows, exceeding recommended limits can lead to slow performance, unexpected errors, or instability. Safeguards help keep your system stable and performing well by enforcing limits on:

• 課題ごとのコメント

• 課題

• 課題タイプ

• プロジェクト

• カスタム フィールド

On this page:

• Safeguards
• Schedule safeguard notifications
• Safeguards limits

When a safeguard is enabled, Jira prevents the creation of new items in that category once the configured threshold is reached. Each safeguard has specific conditions for when preventing is applied, helping you avoid problems before they affect your instance.

Safeguards

課題ごとのコメント

Comments per issue counts all comments in a single issue, then identifies and counts the issues that have more comments than a specified limit. Explore how to find issues with the most comments in the database

By default, Instance optimizer limits each issue to 1,000 comments. When an issue has more than 1,000 comments, the issue view loads slowly, out-of-memory errors might occur, and reindexing takes longer. In extreme cases, Jira can crash.

You can activate the safeguard to prevent users from adding comments after reaching the limit. However, this doesn’t apply when importing or restoring issues. You also need to configure jira.safeguards.config.restricted.groups in Advanced Settings to block comment creation. Otherwise, Jira only sends email notifications when the limit is approached or exceeded.

We recommend to:

• remove older comments through REST API or using ScriptRunner. More about ScriptRunner

• check any automation to make sure you're not adding unnecessary comments. Consider reducing the frequency or batching updates.

• implement rate limiting to prevent a misconfigured integration from adding thousands of comments in a short space of time. More about rate limiting 

Total issues

Total issues counts all the issues in your instance. By default, Instance optimizer limits your instance to have 18,000,000 issues created. You can activate the safeguard to prevent users from adding issues after reaching the limit. However, this doesn’t apply when restoring Jira from backup.

 

The massive number of issues clutters the view in Jira, and therefore, you might wish to archive the outdated issues from your instance. More about archiving issues

A practical way to identify issues for archiving is to focus on those that haven’t been updated for an extended period of time. For example, if there hasn’t been any activity on an issue for two years, it’s a strong indication that it's ready to be archived. It’s also a good practice to archive Done or Resolved issues, or those whose resolution due date has passed.

We also recommend to automate issue archiving. The first step is to identify an optimal retention time for issues. As you decide on that, use the following resources for help with automation:

• Is there an easy way to archive a lot of issues?

• Archive an issue through REST API

Total issue types

Total issue types counts all the issues types in your instance. By default, Instance optimizer limits your instance to have 250 issue types. You can activate the safeguard to prevent users from adding new issue types after reaching the limit. However, this doesn’t apply when importing or restoring issue types.

 

We recommend delete the issue types that you don’t use anymore. You should delete a Jira issue type only after migrating all existing issues of that type to a different, active issue type. This is a necessary step because Jira will prevent you from deleting an issue type if any issues still use it, especially in projects that are still active. Explore how to remove an issue type

You can also use REST API to get a list of all issue types or delete specified issue type and migrate associated issues. More about issue types REST API

Total projects

Total projects counts all the projects in your instance. By default, Instance optimizer limits your instance to have 7,000 projects. You can activate the safeguard to prevent users from creating new projects after reaching the limit. However, this doesn’t apply when restoring Jira from backup.

 

We recommend archiving projects that are no longer in active use. For example, if you find projects whose last issue update occurred two or more years ago, those projects will likely remain inactive in the future. Explore how to archive a project

After you archive a project, it becomes restricted, and both the project and its issues no longer appear in pickers or search. All issues become read-only and accessible only with a direct link.

We also recommend to automate project archiving:

• Create a script that automatically archives or deletes projects. Explore project archiving REST API

• Use the ScriptRunner app to automate your archiving tasks. More about ScriptRunner

Total custom fields

Total custom fields counts all the custom fields in your instance. By default, Instance optimizer limits your instance to have 1,200 custom fields. You can activate the safeguard to prevent users from creating new custom fields after reaching the limit. However, this doesn’t apply when restoring Jira from backup.

You can speed up your Jira by improving the configuration of your custom fields. We recommend using the Custom Field Optimizer feature to identify and optimize custom fields automatically. Optimize your custom fields

 

Schedule safeguard notifications

Jira performance summary emails

Performance summary emails are sent on the specified schedule when any safeguard is approaching (within 10%) a safeguard limit.

You can control how often Jira sends such emails by setting a cron expression in the application property file. The schedule uses the cron expression minute hour day_of_month month day_of_week, with each value separated by spaces.

By using a cron expression, you can specify exactly when safeguard email summaries are sent. For example, the default value 0 0 8 ? * MON schedules emails to be sent every Monday at 8:00 a.m.

To update the schedule, set the following property in your Jira home directory’s application property file, then restart your Jira: jira.optimizer.plugin.safeguards.email.notification.cron. All system admins will receive safeguard email notifications on the same interval.

More about constructing cron expressions

Comments per issue emails

When the Comments per issue safeguard limit is approached, reached, or breached on a specific issue, Jira sends an event-driven email notification. This notification is separate from the Jira performance summary emails.

In-app and personal emails

You can individually opt out of safeguard in-app and email notifications by selecting Disable all safeguard system notifications and email summaries. This setting doesn’t affect the schedule of Jira performance summary emails.

In addition to email notifications, safeguard in-app notifications warn system admins when any safeguard approaches or crosses the 90% threshold of a safeguard limit.

Safeguards limits

You can configure safeguard limits and enforcement using application properties in Jira’s Advanced Settings. More about configuring advanced settings