Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.qlty.sh/llms.txt

Use this file to discover all available pages before exploring further.

Qlty Cloud runs builds with a timeout to keep analysis stable and avoid runaway costs. The timeouts for builds are:
  • Builds for default branches: 20 minutes
  • Builds for pull-request branches: 10 minutes
The timeouts are system-level limits and cannot be increased. If a build is still running when the timeout is reached, it is terminated by the work scheduler.

​
Recognizing build timeouts

Your analysis has likely timed out if you experience any of these symptoms:
  • Build failures — The analysis status fails after running for an extended period, typically due to a timeout. As a result, Build Artifacts may not be available for download.
  • Incomplete logs — When a timeout occurs, the logs may not show a completed analysis and can appear truncated, without the final “analysis completed” line.
  • Issue-limit warnings — “Maximum issue count of 500 reached” followed by a list of skipped files. While these warnings by themselves don’t indicate a timeout, excessive warnings (combined with a failed, incomplete build) can signal that too many files are being analyzed — which can ultimately lead to a time-out.

​
Fixing build timeouts

​
File path exclusions

Analysis timeouts are generally caused by either an abnormally large number of files under analysis or by attempting to analyze files not typically intended for static analysis. Review your project’s exclude patterns to ensure you’re excluding any files or folders you’re not intending to analyze. You can specify file and directory exclusions in your qlty.toml configuration file. Excluding files reduces the time Qlty spends analyzing your project. In general, we recommend excluding:
  • Vendored code
  • Generated code
  • Production assets such as minimized files
  • Dependencies (e.g., /node_modules/, vendor/)
  • Temporary files (e.g., .tmp/, cache/)
  • Large binary files or assets
Example exclusions in qlty.toml: 
exclude_patterns = [
  "node_modules/**",
  "vendor/**",
  "build/**",
  "dist/**",
  ".generated/**",
  "*.min.js",
  "*.bundle.js",
  "coverage/**",
  ".tmp/**"
]
You can also exclude files for specific plugins: 
[[exclude]]
plugins = ["osv-scanner", "trufflehog"]
file_patterns = ["/tests/**"]

​
Linter selection

Certain linters, especially linters which analyze the entire program at once instead of each file individually, can be resource intensive. Disabling expensive linters and/or checks is another dimension which can help. Review which plugins are currently enabled in your project and consider:
  • Disabling computationally expensive plugins that perform whole-program analysis
  • Reducing the scope of expensive checks within plugins
  • Running only essential plugins for time-sensitive builds
You can disable specific plugins in your qlty.toml: 
[[plugin]]
name = "plugin.name"
mode = disabled
Or comment out the specific plugins in your qlty.toml: 
# [[plugin]]
# name = "plugin.name"

​
Increase analysis runner resources

For paid accounts, we now have the ability to increase the size of the analysis runner from the default 2 CPU and 4 GB RAM to larger sizes. This can be found in the Project Settings area. To increase your analysis runner resources:
  1. Navigate to your Project Settings
  2. Locate the Analysis Resources section
  3. Increase the CPU and RAM allocation beyond the default limits
  4. Monitor performance improvement after the change
Note: This option is only available for paid account holders. Step-by-step diagnosis

​
Profile locally

Run qlty check locally with the --verbose --all flags to see which analysis take a high amount of time: 
qlty check --verbose --all
This will show you detailed output about which files and plugins are consuming the most resources during analysis.

​
Isolate problematic plugins:

If the verbose output doesn’t identify the culprit, you can systematically identify resource-intensive plugins:
  1. Remove all plugins from your qlty.toml configuration
  2. Add plugins back one-by-one
  3. Run analysis after adding each plugin to identify which one causes the timeout
This process will help you pinpoint exactly which plugin is causing performance issues.

​
Verification

  • In Qlty CLI: Re-run qlty check --verbose --all locally to confirm runtime is below the timeout.
  • In Qlty Cloud: Re-run your build and monitor performance improvement after any runner-size changes.

​
Getting help

If you have tried the steps above and your build is still timing out, please contact Support for further assistance.