Jira rate limiting
Beginning with Jira 8.6, Atlassian introduced rate limiting to make sure all Jira instances remain stable. It works by limiting the number of external requests that Jira can process in a given period. If the limit of requests is reached, further requests must wait until the next available period. Rate limiting is currently possible in both Cloud and Server/Data Center environments.
The following chapters help you understand how qTest works with rate limiting and how to identify it.
Rate limits in qTest
If rate limiting is enabled, qTest may take longer to retrieve all updates from Jira. Additionally, note the following:
-
If a task in the queue is rate-limited, qTest waits the necessary time before it automatically retries. In the meantime, any other available items are processed.
-
The amount of time required to fully process all requests depends on the number of tasks in the queue and your rate limit.
-
The number of requests you can make before rate limiting applies is determined by Atlassian (Cloud) or your Jira administrator (Server/Data Center). Refer to the appropriate contact if you have questions on your rate limit or performance issues.
Identify rate limiting
Users are informed of rate limiting when:
-
A Jira requirement or release is out of sync.
-
You create, edit, or configure a Jira connection.
-
You retrieve defects in the Add Test Runs > Defects dialog.
-
You link defects in the test execution history.
-
You submit a new defect and link it to a test log or a test step log (includes QuickRun, TestPad).
-
You link an existing defect to a test log or a test step log (includes QuickRun, TestPad).
-
You manually retrieve data of a requirement or a release.
-
You receive code 429 from your qTest APIs requests.