Artifactory Overloading Troubleshooting

Diagnose Artifactory overload from busy worker-thread logs, map activities to root causes, interpret HTTP 429 responses, and decide when to enable Load Healer Reactive mode.

Use this page when Artifactory becomes unresponsive, request latency spikes, clients receive timeouts or HTTP 429 (Too Many Requests), or logs show that all worker threads are busy.

Overload conditions usually mean the Tomcat worker thread pool is exhausted. A single activity, such as one user, one package type, or a dependency waiting on JFrog Xray or JFrog Curation, can monopolize threads and block other traffic.

Before you change capacity settings, identify which activity is saturating the node. Load Healer Automatic Load Protection observes and, when enabled in Reactive mode, can throttle the offending activity so other requests continue.

Prerequisites

Access to Artifactory logs on the affected node
Ability to restart Artifactory if you change Load Healer mode
A monitoring system for Artifactory, especially for production deployments. For related capacity guidance, see Database Tuning for Heavy Loads in Artifactory and High Availability

Confirm Load Healer Is Running

On self-managed deployments, Load Healer starts in Simulation mode by default and does not block requests. During startup, verify the following log entry:

Load Healer mode auto-defaulted to SIMULATION (on-prem deployment)

On JFrog SaaS deployments, Load Healer is enabled by default.

Identify the Activity Causing the Overload

When all worker threads are busy, Artifactory logs every activity consuming more than 20% of the available threads.

all threads are busy (300 out of 300), activities that take above 20% of threads: {...}

These log entries identify which activity saturated the node.

Common activities and what they usually indicate:

Activity in the log	What to investigate
`limitUser`	One user or token is generating excessive concurrency. Reduce client parallelism.
`limitModule` or `limitEndPoint`	One API or package endpoint is dominating traffic. Check CI jobs or scripts targeting that path.
`parallelUploadPreRepoKey`	Concurrent uploads to one repository are too high.
`parallelDownloadUploadPerPackageType`	Download and upload load for one package type is saturating threads.
`xrayBlockUnscanned` or `xrayDownloadBlocked`	Requests are waiting on JFrog Xray. Check Xray health, scan backlog, and blocking policies.
`curationCachedPackageStatus`	Requests are waiting on JFrog Curation approval for cached artifacts.
`qrlLowPriorityRequests`	Database-bound low-priority work is holding threads. Review database load and connection pool sizing.
`limitActivity`	General upload and download load is high across the node.

Troubleshoot Recurring Overload Events

If the same activity repeatedly appears during overload events:

Investigate the workload or dependency causing the overload.
Reduce excessive client concurrency where possible, especially when limitUser appears.
Investigate external dependencies such as JFrog Xray or JFrog Curation when related activities appear.
Consider enabling Reactive mode so Load Healer can protect the instance during future outages. See Enable Reactive Mode.

Verify Reactive Mode During an Outage

After you enable Reactive mode and restart Artifactory, the next time the node enters an OUTAGE (All tomcat working threads are busy and the tomcat connection queue is full) state, look for these log entries.

Starting reactive mode management virtual thread

Setting activities to reactive mode: {<list of activities>}

By default, Reactive mode remains active for approximately 20 minutes before the affected activities automatically return to their previous mode.

Interpret HTTP 429 Responses

When Load Healer intervenes in Reactive mode, only the activity contributing to the overload receives an HTTP 429 (Too Many Requests) response. Other requests continue normally.

If clients retry HTTP 429 with exponential backoff, temporary spikes usually complete successfully.
If clients do not retry, builds or automation may fail during high load.
Sudden bursts of highly concurrent requests are more likely to trigger protection than a gradual increase in concurrency.

Do not treat every HTTP 429 as a capacity defect. First confirm which activity was throttled, then decide whether to fix the workload, dependency, or client retry behavior before increasing system capacity.