Starting the analysis

Qodana implements the static analysis mechanism to automatically analyze your codebase. This means that you run Qodana to analyze your code and expect recommendations for improvements. No other actions like running additional scripts, downloading external libraries, or any additional configuring are required.

Analysis stages

To analyze projects, Qodana performs the project configuration and project analysis stages.

The project configuration stage consists of the following steps:

Project opening. During this step, Qodana converts a project into an internal representation, identifies the project structure, and configures various services like specific language support, file parsing, and VCS handling.
Project configuration. During this step, Qodana lists project files, pulls dependencies, creates indexes, and performs language-specific configuration (e.g. identifies where to look for the Python SDK). More information about performance is available in the Performance optimization chapter.

During the project analysis stage, Qodana iterates through all enumerated files, filters them based on the scope, matches inspections with files, and executes these inspections.

Analysis modes

Qodana can analyze codebases using the regular and incremental modes described below.

Regular analysis

Regular analysis is the default mode that reports all problems found in a codebase and includes all project files in the analysis scope except directories like node_modules or build. You can adjust the analysis scope by configuring inspections using the qodana.yaml file.

The advantages of the regular mode are as follows:

It detects all problems across the whole codebase, including the problems produced by changes in other files
It opens a project only once and can be more favourable for small projects from a performance point of view than incremental analyses
It gives insights into code quality trends

The disadvantages of the regular mode are as follows:

It can be time-consuming for large projects
Analysis reports may contain problems that are not produced by current changes
It requires a configured baseline to eliminate the effect of false positives

Incremental analysis

Incremental analysis limits a regular analysis scope to the files changed between two commits, which are by default the merge-base and source branch head commit files.

This mode reports only problems introduced by changes.

To perform incremental analyses, Qodana is executed twice:

The first analysis uses the merge-base commit
The second analysis uses the source branch head commit

The report contains all problems found in the head commit that were not found in the merge base commit.

The advantages of the incremental analyses are as follows:

It provides faster analysis for mid-to-large codebases
It reports only problems related to the developer’s changes, providing clear feedback

The disadvantages of the incremental analyses are as follows:

It may ignore problems introduced by the changes in other files
It may have inconsistent results when Qodana configuration is changed between states

Start analysis

To analyze your project using Qodana, follow the steps listed below.

Choose the Qodana linter that you would like to use.
Decide which deployment method of Qodana you would like to use.
Configure Qodana as described in the Configuration overview section.
If necessary, set up the list of commands that will be executed before Qodana, see the Run custom commands section for details.
In Qodana Cloud, set up an account and obtain a project token.
Follow recommendations from a linter page that you would like to use (see Step 1 here).

Performance optimization

To improve performance during the project analysis stage, follow these recommendations:

Exclude files from analysis that are not required for the analysis
Save in the VCS information about the excluded directories stored in .*iml files
Use incremental analysis to reduce the scope of files

List of exit codes

Qodana provides the following exit codes:

Exit code	Description
`7`	The EAP license of a linter has expired. Please change the Docker tag either to the next EAP version like `20xx.x-eap` or to a stable version like `20xx.x`.
`137`	Qodana or Docker has crashed due to excessive memory usage. Please increase the amount of RAM available for Docker.
`255`	The number of problems detected by Qodana exceeds a threshold configured by a quality gate.

List of files for investigating Qodana behavior

There are several options for examining Qodana behavior using the /data/results directory:

The /data/results/projectStructure directory.
The Modules.json file in this directory contains a list of all modules detected by Qodana. It should be identical to the list that you expect to see while opening your project in IntelliJ IDEA. If this is no longer the case, check pom.xml for Maven or the build.gradle file for Gradle configurations.
The SDKs.json file in this directory contains the interpreter paths in case of Python.
In the /data/results/ directory, each inspection that detected a possible problem creates its own file named ID.json, where ID is the inspection name that can be used in qodana.yaml for including or excluding inspections. You can find the complete list of inspection IDs in the /data/results/.descriptions.json file using the /groups/*/inspections/*/shortName pattern.
In /data/results/log/idea.log, you can investigate suspicious warnings.

Frequently asked questions

Qodana reports zero errors, but this doesn’t seem correct.

Use the qodana.recommended inspection profile.

If the qodana.recommended profile does not help, try to run another linter.

If the problem persists, please create an issue in our tracker or contact us at qodana-support@jetbrains.com and attach logs from the /data/results directory that you can get access to by mounting your directory to the path.

Is there a way to reduce analysis time?

Yes, you can use caching, and this is available by default in the Qodana Scan GitHub action. If this does not help, create an issue in our tracker or contact us at qodana-support@jetbrains.com and attach logs from the /data/results directory. To access logs, mount your directory. If you are using GitHub actions, they are uploaded to the workflow artifacts.

Qodana fails with the Out of Memory error.

Try to set more memory in Docker Desktop preferences, as some projects and build tools inside them, like Gradle, could require more memory than the default 2 GB.

Qodana can't download Gradle because I use proxy.

Before starting Qodana, please run the ./gradlew command in the root folder. This will let Qodana use this downloaded version of Gradle.

If your project was created on Windows, make sure to run git update-index --chmod=+x gradlew to make the file executable in your CI.

I have accidentally uploaded sensitive data to Qodana Cloud, what should I do?

All your data is always encrypted at rest and in transit. If you remain concerned, you can delete the report containing sensitive data using the Qodana Cloud UI.

01 April 2026