Troubleshooting Slow Vibgrate Scans

This article helps you diagnose and fix slow Vibgrate scans. It is for developers working in large repositories or monorepos where a scan takes longer than expected.

Start with scope

The fastest scan is one that analyzes only what matters. Exclude directories that do not need analysis, such as build output or vendored code:

vg scan --exclude dist

If your repository has many unrelated projects, scope the run to the directory you care about:

vg scan --cwd packages/app

Tune parallelism

Large repositories benefit from more concurrency. Increase parallel work with the concurrency or jobs controls:

vg scan --concurrency 8

On constrained CI runners, the opposite can help — lowering parallelism avoids resource contention.

Use the cache

The CLI caches work between runs. Avoid forcing a full recompute unless you are debugging a stale-result problem. If you previously added --no-cache, remove it for routine runs so subsequent scans reuse prior work.

Speed up code-map queries

If the slow part is vg ask rather than scanning, precompute the semantic index once so the first query is instant:

vg embed

After this, code-map queries run locally and offline.

Quiet output in CI

Verbose console output can add overhead and noise in pipelines. Reduce it:

vg scan --quiet

When it is the network

A pure local scan should not wait on the network. If a run stalls on network access, force local-only behavior to confirm:

vg scan --offline

If offline is fast, the delay was a network or proxy issue — see the proxy and offline configuration article.

Related

• Proxy and offline configuration
• Global flags reference
• The vg scan command page