Bartosz Ornatowski added a comment - 11/Apr/2022 5:50 AM - edited Hello, Thank you for your patience waiting for an update for this issue. JSM and Jira teams have investigated this issue and addressed the behaviours that contributed to this bug.  Root Cause Excessive amount of reindexing calls for a large amount of issues in a short period of time may cause the indexing queue overflow. JSM Footprint When an SLA configuration is updated or a new SLA is created, JSM will fetch all the issues affected by the change, calculate the new SLA value, save it to the DB, and then  reindex all changed issues. More on how we recalculate SLAs can be found here . For JSM to have a significant footprint on indexes, the project will have to have 50k+ tickets, and a large portion of them needs to be affected by the configuration change which is in most scenarios  not the case as JSM would only recalculate ongoing cycles, and in general scenario the majority of historical tickets would have the SLAs completed. Nonetheless, there are scenarios where such changes are made. A side note here: in our testing, we have found that sheer number of issues is not enough to overload the indexing queues. Issues with a significant amounts of worklog, history and/or comments need to be present in the affected project for this issue to manifest itself. Contributing factors Other plugins that call reindexing in their operation. One example would be Automation for Jira plugin that has a rule configured that is triggered by issue or SLA update event. Chained rules would additionally exacerbate the indexing strain. Custom scripts that call reindexing Slack integration that calls reindexing And similar 3rd party plugin behaviour Large amounts of worklog, history and/or comments in the affected tickets A busy instance where many creation or update events happen during SLA configuration change Mitigation options When updating an SLA configuration on a large project, assess the scope of the change, and avoid making big changes during peak usage hours for your instance. Consider your custom scripts. Do they need to call Jira's reindex API? Since Jira 8.0, index has become much more reliable, and this step is considered an unnecessary overhead in most cases. Consider the scope of reindexing in your scrips. The API allows you to choose to reindex only the parts that you need for your script to work properly. Since Jira 8.19.0, the default call to issue reindex has been changed to reindex issue only. Read more here . Product improvements Jira's indexing queue size has been increased 4 times in order to prevent queue overflow (since 4.13.8+/4.16.1+). JSM indexing calls post SLA configuration change have been halved (since 4.13.12+/4.16.1+) Jira has fixed the default reindexing API behaviour to reindex only the issue scope (since 4.19.0)