DiagScope — Static analysis for Java & Kotlin

Three ways in

Pick where it fits your workflow

01 — In your build

Maven plugin

mvn verify fails by the tolerance you set. One POM entry, nothing else to install.

Set it up →

02 — With your AI assistant

Check generated code

Instructions and a hook make the assistant run DiagScope before it says it is done.

See how →

03 — Standalone

No dependency in your project

A CLI for any build and any CI, from Homebrew or a JAR. For when a build plugin is not welcome.

Install it →

In your Maven build

Fail the build, not the production

A Maven plugin runs DiagScope during mvn verify and fails the build by the tolerance you chose. It is on Maven Central: no repository to add, and nothing else to install.

Add it to the POM

One plugin entry. With no gate configured it only reports, so you can adopt it first and tighten later.

<plugin> <groupId>io.github.diagscope</groupId> <artifactId>diagscope-maven-plugin</artifactId> <version>0.1.8</version> <executions><execution> <goals><goal>scan</goal></goals> </execution></executions> </plugin>

Choose how strict to be

The same diagscope.yml that governs the command line governs the build. Or decide per run, or per branch with a profile.

$ mvn verify -Ddiagscope.failOn=ERROR \ -Ddiagscope.failOnConfidence=HIGH $ mvn verify -Ddiagscope.gateProfile=release

Run it once

No edit to the POM: useful to try it on a project, or in a pipeline step of its own.

$ mvn io.github.diagscope:diagscope-maven-plugin:0.1.8:scan \ -Ddiagscope.failOn=ERROR

Maven runs on JDK 17 or newer. In a multi-module build each module is judged on its own, pom modules are skipped, and one diagscope.yml at the root governs them all. The analyzer comes with the plugin: one download of about 78 MB, cached afterwards.

With AI assistants

Let your coding assistant check its own work

When a team generates code with an assistant, DiagScope can run before the assistant says it is done, so swallowed errors and missing logs are fixed in the same session instead of in production.

Set it up once

Writes a short instruction block into AGENTS.md and CLAUDE.md, and adds a Claude Code hook that scans the changed files when a task ends. Existing content is never overwritten.

$ diagscope init-agent

Output made for assistants

Compact plain text, worst finding first, a fix line for each. About 3 KB where the Markdown report has 22 KB. The exit code still comes from your gate.

$ diagscope scan --format AGENT \ --files src/main/java/PaymentService.java

Choose how strict to be

Tolerance lives in diagscope.yml, so it is reviewed with the code. Fail on high-confidence errors, tolerate a few warnings, or define a stricter profile for release branches.

gate: failOn: - severity: ERROR confidence: HIGH maxFindings: { WARNING: 20 }

The automatic hook is for Claude Code. Other assistants read the instructions in AGENTS.md and run the same command, but nothing forces them to. A scan takes 1 to 15 seconds depending on project size, so the check runs when the task ends, not after every edit. The assistant is told not to silence a finding without asking you.

Standalone

No dependency in your project

The same analyzer runs on its own. Use it when your company does not want a build plugin, when the build is Gradle, or to look at a repository you do not own. Nothing is added to the project.

Install

Homebrew brings Java 17 with it. Without Homebrew, download the JAR and run it on Java 17 or newer.

$ brew tap DiagScope/tap $ brew install diagscope

Scan a project

No build step. REST endpoints, Kafka listeners and scheduled jobs are found as entrypoints; reports land in target/diagscope or build/diagscope.

$ diagscope scan --project .

CI gate — only new findings

Fail the build only on findings introduced in this pull request, and leave the existing ones for later.

$ diagscope scan --project . --update-baseline $ diagscope scan --project . --baseline --fail-on ERROR

Explain a finding, browse the rules

The full description, why it matters and how to fix it; the catalog lists every rule with its severity, category and version.

$ diagscope explain SILENT_CATCH $ diagscope rules

What it finds

Code that fails silently

Exceptions, transactions, concurrency, Kafka, performance, security, and more. Every finding names the entrypoint that reaches the problem.

SILENT_CATCH

Swallowed exception

Caught and never logged or re-thrown — the failure simply disappears.

FUTURE_GET_WITHOUT_TIMEOUT

Blocking call without timeout

A thread hangs indefinitely waiting for a result that may never come.

MISSING_TRANSACTION_ANNOTATION

Write without transaction

If a later step fails, the first write is committed and cannot be rolled back.

HTTP_TIMEOUT_NOT_SET

HTTP call with no timeout

A slow upstream exhausts the thread pool and takes the whole service down.

N_PLUS_ONE_QUERY_RISK

N+1 query in loop

A database call inside a loop — scales linearly and degrades with data growth.

KAFKA_SEND_RESULT_IGNORED

Kafka send not observed

The publish result is dropped — failures are invisible to the caller.

Report

What the report looks like

Open report.html in any browser. It is one self-contained file: no server, no network. It ranks what to fix first, filters by severity and confidence, and shows the call path from the entrypoint to each finding.

Find the code that hides failures before production does

Pick where it fits your workflow

Maven plugin

Check generated code

No dependency in your project

Fail the build, not the production

Add it to the POM

Choose how strict to be

Run it once

Let your coding assistant check its own work

Set it up once

Output made for assistants

Choose how strict to be

No dependency in your project

Install

Scan a project

CI gate — only new findings

Explain a finding, browse the rules

Code that fails silently

Swallowed exception

Blocking call without timeout

Write without transaction

HTTP call with no timeout

N+1 query in loop

Kafka send not observed

What the report looks like

Try it on your own code.