Check Graph Status and Freshness with vg status

A code map is only trustworthy if it reflects your current code. vg status tells you whether it does — reporting freshness, size, staleness, and how the map was resolved. This article explains each part of the output and how to act on it.

Overview

vg status compares the committed (or built) graph against your current working tree. It reports node and edge counts, whether the graph is stale relative to your code, and the resolver rungs that were used to build it. In short, it answers: “Is my code map current, and how big is it?”

Prerequisites

A code map should exist. If not, build one:

vg build

Check status

vg status

Read the output as a health check:

• Node and edge counts describe the size and connectivity of the map.
• Staleness tells you whether the graph lags behind your working tree. A stale graph means recent edits are not yet reflected.
• Resolver rungs indicate how thoroughly the code was resolved when the map was built.

Acting on staleness

If vg status reports the graph is stale, rebuild it so downstream queries are accurate:

vg build

Then re-run vg status to confirm it is current. Keeping the graph fresh ensures that vg map, vg hubs, vg ask, vg impact, and the rest operate on up-to-date structure.

Using status in workflows

vg status is a natural gate. Before you rely on graph output — in a review, a refactor, or a pipeline — run it to confirm the map matches the code. For automated use, see graph status in CI.

Related

• Build or update the map with vg build.
• Make the map committable with vg share.
• Get a structural overview with vg map.

Status is computed entirely from local artifacts and your working tree.