Description:

Customers utilize the Get issue limit report API endpoint (/rest/api/3/issueLimit/report) as a proactive monitoring tool. It allows administrators to identify work items approaching hard system limits (such as the 10,000 worklog limit) so they can intervene before users experience errors.

Current Behavior:

The API currently queries raw database row counts. If a work item has 9,000 worklogs but is already in a "Closed" status and has been archived within its space, the API continues to return this work item in the report permanently.

Pain Point:

Because closed and archived work items are no longer actively receiving new data, they will never actually hit the limit. However, they permanently populate and pollute the limit report, entirely defeating the endpoint's proactive monitoring purpose. Customers should not have to manually move historical worklogs off of closed/archived work items just to clear them from this API report.

Suggested Resolution:

Provide long-term flexibility to this endpoint by allowing users to filter out inactive data.

• Add an optional query parameter (e.g., statusCategory!=Done or excludeArchived=true).

• Alternatively, update the default behavior of the API to exclusively evaluate active work items.

Workarounds: (must be validated)

• Workaround 1 (Post-Processing via JQL - Recommended): Instead of relying on the API to filter out closed issues, perform a secondary validation on the returned data.

• • If using Jira Automation: After the "Send web request" action, add a Lookup Issues action using the JQL: key in ({{webResponse.body.issueKeys) AND statusCategory != Done AND status != Archived{}}}. Then, base your notification or alerting logic only on the {{lookupIssues}} smart value.

• • If using an external script: Parse the returned JSON payload to extract the issue keys, then make a secondary POST /rest/api/3/search call using the same JQL to filter out the inactive ones before triggering alerts.

• Workaround 2 (Data Reduction): If historical time-tracking data on the archived issue is no longer required for reporting, utilize the Bulk Delete Worklog API or Bulk Move Worklog API to reduce the row count on the database below the threshold limit.