Consolidate SLAs in Jira Service Management
This recommendation is shown when your service projects exceed the guardrails for SLAs or SLA goals, and Jira issue performance is impacted by JQL querying or loading SLA custom fields.
Signals used
Details of how we detect this issue.
Conditions
The following conditions need to occur together:
At least one key experience, such as viewing or editing an issue, shows degraded page load times (RFU).
Some projects exceed the guardrail for SLAs or SLA goals
RFU HTTP requests show that a significant amount of time is being spent on JQL querying or loading issue fields, including SLA custom fields.
How we detect it
Signal | Details |
|---|---|
RFU degradation | We look for Ready for User (RFU) degradation - cases where key Jira experiences take significantly longer than their historical baseline. This helps us confirm that users are actually experiencing slower page loads, not just one-off spike. |
RFU HTTP request metrics | We use RFU HTTP request metrics to see how time is spent during page loads. We look for requests where a large proportion of the total time is taken by JQL execution or by loading issue fields, which can include SLA custom fields. |
Field loading metrics | We use field loading metrics to identify when custom fields are contributing heavily to issue load time. If SLA custom fields are present and field loading time is high, it suggests that SLA fields are part of the performance problem. |
Jira Service Management metrics | We use metrics specific to Jira Service Management to understand how SLAs impact the index. Each SLA adds multiple indexed custom fields, which increases index size and can slow down indexing and querying when there are many SLAs configured. |
SLA statistics vs guardrails | We use SLA statistics to determine how many SLAs and SLA goals are configured in each project and compare these counts to the Jira Service Management guardrails. |
Filters
When this issue occurs multiple times, we group occurrences under different time filters, for example a 24‑hour or 7‑day period. In this case:
For degraded experiences, we show the highest degradation from all occurrences in the selected time filter, focusing on JQL execution time and issue field loading time.
For identified projects, we highlight service projects whose SLA and SLA goal counts exceed the guardrails. We also provide a CSV file with the details of these projects.
Frequency chart
The frequency chart shows how often this issue has occurred over time. This can help you identify patterns such as:
periods where JQL querying and field loading are repeatedly slow in projects with many SLAs
whether consolidating or removing SLAs reduces how often this recommendation appears
Recommended actions
Review projects exceeding SLAs or SLA goals
Download the CSV file to review the projects exceeding SLAs or SLA goals. For each project ID, we’ll provide the count of SLAs and SLA goals, together with the current guardrail. Because of lack of user-generated content, we can only provide projects IDs - you’ll need to use the following REST API to identify them:
Consolidate or remove overlapping SLAs and SLA goals
Review each SLA to determine whether it’s still required and whether similar goals can be combined. In many instances, multiple SLAs track very similar conditions where a smaller set of well-designed SLAs would be sufficient.
Consider merging SLAs that differ only slightly in their conditions or targets, or removing SLAs that are rarely used. Reducing the number of SLAs and goals lowers the number of SLA custom fields that need to be calculated, stored, and indexed for each issue, which can improve both indexing and query performance in affected projects.
Was this helpful?