A scheduled QA flow stops updating release-readiness notes. Some work items may already have changed, others may still be waiting, and the last visible error may describe only one attempted execution. Restarting the flow before identifying the restriction can increase load without resolving the missing readiness evidence.
For Jira Cloud automation limits for QA, start with two separate questions: did the flow breach a service protection, and did the applicable monthly usage allowance prevent further execution? Answer both against matching audit and usage evidence. Neither a busy usage chart nor a stopped flow identifies the cause on its own.
Do not assume that a monthly automation cap still means a count of successful rule runs. Atlassian's current automation usage reference describes executed automation steps pooled at the organization level. Triggers, conditions, actions, branches and loops that execute contribute to that meter. This differs from older explanations based on successful runs and separate product allowances.
There is a documentation compatibility issue to resolve before using a run counter. As checked on October 24, 2026, the current usage reference describes the move to steps and separately states that extra-usage billing takes effect on December 3, 2026. An Atlassian comparison KB, explicitly labeled AI-generated, still describes successful-run accounting and product-specific monthly pools. The current usage reference and billing documentation are the basis for the step-based explanation here; neither proves the migration state or entitlements of your particular organization.
Ask the organization administrator to confirm the actual meter, organization, contributing subscriptions, plan and usage period shown for your environment. If your screen still presents runs, preserve that evidence and resolve its applicability rather than translating runs into steps yourself. A flow execution count is not interchangeable with a step count.
The current billing reference describes allowance resets at the start of the monthly billing cycle. Do not substitute an assumed first-of-month reset, a subscription renewal date or a date copied from the AI-generated KB. Record the applicable usage-period boundary confirmed by the administrator. No plan allowance, purchase or billing change should be inferred from this diagnostic guide.
The two restrictions govern different populations and clocks. Service protections constrain how automation processes work, including work fetched by a flow, processing within a defined time window, queued work across flows and concurrent execution. Monthly usage accounting measures the applicable allowance consumed over its usage period. A flow can encounter a service restriction while monthly capacity remains available, and both restrictions can also exist together.
Atlassian's service-limit reference identifies THROTTLED as an audit status that may indicate a breach, with further detail in the audit entry. Read that detail before choosing a remedy. A processing-time message calls for a different investigation from a JQL retrieval limit or excessive queued work, even when the visible result is that the QA flow stopped progressing.
Bind the message to its flow, execution time and applicable reference row. Keep the row's scope and unit intact: work items fetched, queued items, concurrent flows and processing time are not interchangeable measures. In particular, elapsed wall-clock time does not by itself establish the processing allowance consumed by a branched flow.
The AI-generated comparison KB disagrees with the service reference on concurrent execution and processing windows. Use the current service reference for the relevant app and plan, retain the exact audit detail, and seek clarification if the observed behavior still conflicts. Do not configure recovery around a numeric ceiling copied from that KB. This guide deliberately omits the disputed thresholds.
Also check whether the flow is enabled. The service reference describes disablement for a particular associated-items breach; that does not make every THROTTLED entry proof that the flow was disabled. An enabled flow may still be constrained, while a disabled flow needs an authorized decision before anyone considers re-enabling it.
For the currently documented step model, compare usage with the matching organization's allowance and controls. The reference says flows stop at exhausted allowance when extra usage is disabled. It also describes continued operation with extra usage enabled. A high percentage, or even consumption beyond included allowance, therefore does not establish an enforced stop without the applicable policy evidence.
Counting also differs from the older successful-action rule. The current reference includes executed components with certain no-change, no-match or business-error outcomes. A no-action result is not a universal guarantee of zero usage. Conversely, THROTTLED runs where no step actually executes are excluded from the documented step count. Preserve the component outcome rather than classifying every unsuccessful-looking run as free or every throttled run as charged.
Organization administrators can inspect step usage in Atlassian Administration under Insights, then Platform usage, according to the current reference. Confirm that this documented route and meter apply to your organization. Keep operational execution counts and duration charts separate: performance insights help locate busy or slow flows, but do not independently establish the monthly accounting total.
Create a diagnostic record before proposing changes. The following is an authored worksheet procedure, not a list of additional Jira audit fields or a claim that every observer has administration access.
If the evidence does not match, leave the cause unknown. An old audit excerpt from another flow cannot diagnose the current stop. A high-usage screenshot from another period cannot establish current exhaustion. Where limits remain unsupported, investigate whether the trigger occurred, a condition excluded the intended work or permissions prevented an action. Do not force a limit diagnosis onto a flow that never reached the expected action.
QA-LIMITS-PACKET-1.0 is an unexecuted teaching example, not a customer incident or a measured Jira response. It uses the same fictional Jira Cloud Premium flow throughout: a scheduled release-readiness flow finds release work items, traverses related QA subtasks and updates readiness notes. Its organization administrator is assumed to have confirmed the current automation-steps meter and monthly usage period. These are scenario assumptions, not evidence that a real tenant exposes that configuration.
The table summarizes authored worksheet observations and derived decisions. THROTTLED is a documented status; phrases such as “allowance available” and the case labels are worksheet descriptions, not invented official audit statuses.
Packet Evidence | Supported Diagnosis | Next Safe Decision |
|---|---|---|
A: Matching THROTTLED processing detail; current allowance available | Service protection evidenced; monthly exhaustion not evidenced | Jira administrator and QA lead preserve partial work and review bounded load changes |
B: Matching monthly allowance exhausted; extra usage disabled; no supplied service-limit entry | Monthly usage exhaustion evidenced; service protection not evidenced | Organization or billing administrator verifies capacity; QA lead holds recovery |
C: Old audit excerpt from another flow; high usage from an unmatched period | Unknown; neither cause established | Jira and organization administrators obtain matching evidence before recovery |
In case A, the matching audit detail begins, “Automation for Jira has exceeded the allowed total processing time for this flow.” The assumed usage record shows capacity available in the confirmed period. That supports a service-protection investigation, not monthly exhaustion. Which readiness notes already changed, whether the flow is enabled and whether peer schedules contributed to load remain unknown. The Jira administrator and QA lead should preserve partial work and review narrower retrieval and less frequent scheduling before considering an authorized bounded retest.
In case B, matching usage evidence establishes exhausted monthly allowance with extra usage disabled. No matching service-limit entry is supplied. Monthly exhaustion is supported, but absence of supplied service evidence does not prove that service risks are impossible. The organization or billing administrator must verify the applicable reset date and controls, while the QA lead holds recovery until capacity and prior execution effects are reconciled. Rescheduling the flow cannot be treated as replenishing that allowance.
Case C supplies a THROTTLED excerpt from another flow and an unmatched historical period, plus a high-usage screenshot with no matching organization or period. Neither diagnosis is established. The Jira and organization administrators need matching current evidence; the intended trigger, conditions and permissions remain open investigation paths. Re-enabling or replaying work would turn an evidence gap into an operational experiment without a justified recovery decision.
These cases classify evidence, not readiness to resume. If both matching service evidence and confirmed blocking monthly exhaustion appear, record both causes. Resolving one does not establish that the other has cleared or that earlier QA updates completed.
Choose a proposed change against the restriction actually evidenced. The objective is to reduce unnecessary processing while retaining the release-readiness work the QA lead requires. A smaller query that silently excludes required evidence can make automation look healthier while making the QA report less complete.
The service guide recommends limiting JQL to the smallest necessary work-item set and reducing work fetched through triggers or related-work branches. For the fictional readiness flow, review project and release scope, relevant statuses and the related QA subtasks genuinely needed for the readiness decision. Review each branch separately; narrowing the initial search does not automatically bound every later retrieval.
Avoid creating related-work branches merely to simulate a simple conditional check when an appropriate condition can express the decision. This is a proposed structural review, not proof that a particular branch is unnecessary in your flow. Preserve the expected readiness output and have the QA lead approve any reduction in scope.
The documented changed-since-last-execution option can reduce repeat retrieval when that subset fits the workflow. It is unsuitable as an automatic recovery shortcut if unchanged work items still carry due QA obligations or incomplete earlier updates. Confirm how those obligations will remain covered before adopting the option. A narrower result set neither proves the backlog was completed nor restores consumed monthly allowance.
The service reference recommends running repetitive scheduled work less frequently where appropriate. Agree the acceptable delay in readiness reporting before changing the schedule. A frequently repeated scan can consume processing capacity even when few readiness notes need to change; lengthening the interval may reduce repeated work, but its effect is unmeasured until observed in the applicable environment.
Review other relevant schedules when queued work or concurrency is implicated. Staggering their start times is a proposed load-management design, not a documented guarantee of queue clearance or throughput. Confirm that the flow's own execution and the shared workload fit the applicable service protections. Schedule changes cannot refund prior monthly usage, prove partially executed actions succeeded or authorize processing an entire unresolved backlog.
Keep decision authority separate from the person executing a change. As a proposed governance convention, the QA lead approves required coverage and readiness expectations; a permitted Jira administrator owns flow changes and any re-enable or retest operation; an organization or billing administrator verifies allowance and usage controls. These roles do not grant permissions, and this guide performs none of those actions.
Before an authorized recovery attempt, require a supported cause, reconciled prior effects, confirmed capacity under the applicable meter and a reviewed bounded input set. Define the expected readiness changes, the evidence to inspect afterward and the condition that will stop the attempt. Where enabled state or completed work is still unknown, resolve that uncertainty first. Do not replay all earlier work merely because the last execution ended in an error.
If the flow was disabled, re-enabling is a proposed action only after its cause and recovery prerequisites are addressed. If it remained enabled, toggling it is not a substitute for diagnosis. After a permitted bounded retest, review both its audit evidence and the intended work-item effects, together with applicable usage evidence. A cleaner audit entry alone does not establish complete release-readiness information.
When QA automation stops, the useful next step is a matched evidence record and an owned recovery decision. Preserve what happened, identify the actual service and monthly scopes, and resume only when the authorized reviewers can explain what the next bounded execution is expected to do.
A tester reviewing a Jira issue may need a fresh smoke run without opening GitLab and choosing pipeline parameters. A manually triggered Jira Cloud…
A sprint can contain carefully estimated testing work and still overload the only person who can perform it. The missing input may be a…
A regression-results worker receives HTTP 429 while reading Jira issues. Sleeping that worker may be necessary, but it will not help if other workers…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
