Running snyk test against a repository gives you a pass/fail read on the dependencies sitting in your working directory right now, then the process exits and that result evaporates. snyk monitor does something different: it packages up the resolved dependency tree at that exact moment, uploads it to Snyk's platform as a named Project, and leaves it there to be re-checked automatically as Snyk's vulnerability database changes. That single command is what turns a one-off scan into a standing inventory entry — the mechanism behind the dashboards, email alerts, and "new vulnerability disclosed" notifications that show up days or weeks after anyone touched the code. Most teams run snyk monitor dozens of times a day without thinking about what it's actually recording or how long that record stays authoritative. This post walks through what a snyk monitor snapshot contains, how Snyk decides whether to create a new one or update an existing one, and where the point-in-time model has known gaps — using only Snyk's publicly documented CLI and platform behavior.
What does a snyk monitor snapshot actually contain?
A snapshot is a resolved dependency graph, not a copy of your source code. When you run snyk monitor in a project directory, the Snyk CLI invokes the same language-specific resolution logic it uses for snyk test — the npm/Yarn resolver for package-lock.json or yarn.lock, Maven's dependency plugin for pom.xml, pip/poetry resolution for Python, Bundler for Ruby, Go modules for go.mod, and so on — to build a full tree of direct and transitive dependencies with their exact resolved versions. That graph, along with manifest metadata, the detected package manager, and applicable license identifiers per package, is what gets sent to Snyk's backend. A Node.js service with 40 declared dependencies in package.json can easily resolve to 600–1,000 entries once transitive packages are included, and it's that full expanded tree — not the 40-line manifest — that becomes the snapshot. No application source files are uploaded; the payload is dependency and license metadata only.
How is a monitor snapshot different from a project entry in the Snyk dashboard?
The snapshot is the data; the Project is the container it lives in. Each snyk monitor run produces a timestamped snapshot, and Snyk groups those snapshots under a Project identified by the combination of org, project name, and target reference (typically the git branch). The CLI's output after a successful run prints a confirmation link that resolves to something like https://app.snyk.io/org/<org-id>/project/<project-id>/history/<snapshot-id> — the history segment is the giveaway that what you're looking at is one entry in a chronological log, not a live view of your repo. Open the Project page in the dashboard and you'll see the most recent snapshot's results by default, with a history tab exposing prior runs. That history is what lets a team look back and ask "were we exposed to this CVE on the release we shipped on June 3rd?" — a question snyk test alone can't answer once the terminal output scrolls away.
When does a monitor run create a new Project versus update an existing one?
Snyk keys Projects on target reference, so pushing repeated snyk monitor runs against the same branch updates the same Project's history rather than spawning duplicates. The --target-reference flag (or the branch name Snyk auto-detects from git context) is the identifier that ties snapshots together; --project-name controls the display label. Run snyk monitor on main ten times over a week and you get one Project with ten history entries. Run it against a feature branch and, depending on org settings and the integration used, Snyk will typically either open a separate Project for that branch or fold it under the parent repo's Project with the branch tracked as metadata. This is also why teams that run snyk monitor --all-projects inside a monorepo with multiple manifests (say, a root package.json plus three service-level pom.xml files) end up with multiple distinct Projects from one CLI invocation — one per detected manifest, each accumulating its own snapshot history independently.
How does an old snapshot get flagged for a vulnerability disclosed after it was taken?
The snapshot itself is never re-scanned in the sense of re-reading your files — Snyk instead re-runs its vulnerability database against the frozen dependency list already on record. Because the dependency graph and exact resolved versions are already stored from the original snyk monitor call, checking that list against a newly added CVE is just a database lookup: does any package@version in this snapshot match the affected range in the new advisory? Snyk's documentation describes monitored Projects being tested automatically whenever the vulnerability database is updated, which is how a dependency that was clean on Monday can generate an alert on Thursday with no commits in between — the code didn't change, the advisory did. For Projects connected through a Git integration (GitHub, GitLab, Bitbucket, Azure Repos) rather than the raw CLI, Snyk also exposes a configurable test frequency in project settings, so an org can additionally request periodic re-imports on a schedule independent of push events.
What actually triggers a snyk monitor run in a normal pipeline?
In practice, almost nobody runs snyk monitor interactively — it's wired into whatever already runs on merge. The three common triggers are a CI step added after tests pass on the default branch (a snyk monitor line dropped into a GitHub Actions, GitLab CI, Jenkins, or CircleCI job), Snyk's native Git integration auto-monitoring a repository whenever commits land on the branch it's configured to watch, and scheduled/cron jobs some teams add to force a fresh snapshot even on days with no code changes. Because snyk monitor doesn't fail the build (unlike snyk test, which is typically the gate on pull requests), it's safe to place after deploy or merge steps without risking a broken pipeline on a newly disclosed vulnerability. The practical effect is that most orgs' Snyk history shows one snapshot per merge to main, not one per commit or one per day.
Where does the point-in-time snapshot model fall short?
The core limitation is the gap between snapshots: anything that happens to a package after the last snyk monitor run and before the next one is invisible until that next run occurs. If a team merges to main twice a week, a malicious or vulnerable version published to npm on a Tuesday sits unflagged in the dependency tree until the next scheduled snapshot picks it up — the vulnerability database check only fires against packages already recorded in an existing snapshot, so a brand-new advisory for a version nobody has monitored yet produces no alert at all until someone runs snyk monitor again. The model also snapshots resolved versions from the lockfile at commit time, so it reflects what was pinned, not necessarily what actually got installed in a given build environment if lockfiles are absent, ignored, or overridden. And because target reference determines Project identity, branches that get renamed, rebased, or deleted without a final monitor run can leave stale history that no longer maps to anything deployed.
How Safeguard Helps
Snapshot-based scanning like snyk monitor is built to answer "what did our dependency tree look like the last time we checked it" — which is valuable but leaves the space between checks largely unmonitored, and it stops at the manifest boundary rather than following a package through the build, registry, and artifact pipeline that actually ships it to production. Safeguard is built around continuous visibility into that broader supply chain: tracking package and build provenance as artifacts move from source to registry to deployed workload, flagging registry-level changes (a new version, a maintainer change, a yanked release) as they happen rather than waiting for the next scheduled scan to notice them, and correlating dependency risk with what's actually running rather than only what's declared in a lockfile at merge time. For teams already relying on point-in-time SCA snapshots, Safeguard is a way to close the gap between them — surfacing supply chain risk as it emerges instead of only at the cadence your CI happens to run.