Fallow Cloud is analytics for your code.

Page analytics counts the visits to each page. Fallow Cloud counts the production calls to each function, keeps each deployment's counts separate, and puts them on a map of the whole codebase. People and coding agents read the same numbers: which code is hot, what changed after a deploy, and which code nobody runs.

Try Fallow Cloud free for 30 daysnpx fallow

The trial needs no credit card. After 30 days, Fallow Cloud is $20 per seat per month. The Fallow scan it is built on is free and open source under MIT.

Connect your code graph to production call counts.

Fallow started as a static scan. It reads every import in the repository and builds one graph of the code. That graph shows how the code connects, but not how production uses it. On paper, the checkout and a partner export that nobody opens look the same: both are reachable, and a scan has to treat them the same way.

Page analytics counts visits to each page. An APM tool samples requests, so a call that happens twice a month may never appear in a sample. An error tracker records reported failures. Fallow Cloud adds call counts per tracked function and compares deployments.

FallowEvery function and every import, read from the repository.

Fallow CloudThe same map with 30 days of production calls. The thick lines carry the most calls, and the dashed branches had none.

Both maps are illustrations, not real counts.

A package in each service counts the calls, and Fallow matches every count to a function.

Add the package to a service
@fallow-cli/beacon runs inside a production service and counts how often each function runs. It counts calls instead of sampling requests. It works on Node, Bun, Deno, serverless platforms and in the browser. On Node that is one setting. Bun, Deno and the browser need one extra build step.
Upload the function list from CI
After each deploy, CI runs fallow coverage upload-inventory. It sends the list of functions in the deployed commit, which tells Fallow Cloud what could have run.
Match the counts to the list
Fallow Cloud matches the counts to the function list for the same commit. Tracked functions with no calls show zero. Functions without runtime evidence stay untracked. Calls from tests and CI stay separate and never count as production traffic.
Read the result where you work
The dashboard at fallow.cloud keeps the history of each deployment. The same data reaches the terminal through fallow coverage analyze --cloud and coding agents through the MCP server.

Tracked functions fall on one scale, from hot to not called.

The window is 7, 30 or 90 days of the current deployment. The scale tells people and agents where to spend their time.

Hot.
Production calls it all the time. Review every change to it line by line, and test it first.
Warm.
Production calls it every day at a normal volume. Normal care is enough.
Cold.
Production calls it a few times a month. Ask whether you still need it before you spend more time on it.
Not called.
No production calls in the window. Check the deletion verdict and its evidence before you remove it or leave it out of a migration.

Each deployment gets a report, next to the one before it.

The dashboard compares calls per hour because deployments run for different lengths of time. Rate changes and stops appear after both deployments have at least 6 hours of observations and the new deployment has passed its warm-up. Before that, the report shows only new code that already ran.

Heated up.A function runs at least twice as often per hour as in the deployment before. A new feature can do that, and so can a loop or a retry that nobody meant to add.
Cooled down.A function runs at most half as often per hour as before. Traffic moved to other code, or a path stopped working for part of your users.
Stopped.Production called the function in the previous deployment and has not called it in the current one. This can reveal a change that produced no reported error.
New code, not called yet.The deployment added the function, and production has not called it. The feature may wait behind a flag, or its route may not work.

Next to the report, the dashboard keeps a timeline of every deployment, lists the functions of a repository with the most calls first, and marks each line of a source file as run or not run.

Coding agents check and focus their work with the same numbers.

Developers read less of the code line by line. The counts tell an agent where to be careful, and tell a reviewer where to look.

Before a change.Through the MCP server, an agent asks how often production calls the function it is about to change, how many callers it has, and its risk band. A hot function gets a small change and a test first.
To focus the work.The hot paths show an agent which functions production calls most. It can focus its effort on those functions.
In review.A reviewer runs fallow coverage analyze --cloud and gets the hot paths of the repository. The changed functions on those paths get a line-by-line read. The rest gets a quick look.
The same numbers for both.The agent and the reviewer use the same call counts from the same deployment to assess the change.

When the question is deletion, a verdict comes with the evidence.

The CLI and the MCP server give each function one of five verdicts, with a confidence level. A staff engineer can check every number before anyone deletes a line.

Fallow Cloud verdicts
Verdict	What the code and the counts show	What your team does
Safe to delete`safe_to_delete`	No file imports the function, and production called it zero times in the window.	Delete it based on the static analysis and zero calls in the observed window.
Review required`review_required`	Other files import the function, but production called it zero times.	A person checks it before anyone deletes it. The code can be seasonal, run only on an error path, or be dead.
Low traffic`low_traffic`	Production calls it, but below a threshold, which is 0.1% of all calls by default.	Find out who still calls it before you plan the removal.
Coverage unavailable`coverage_unavailable`	The package could not track the function, for example code in a worker thread or code that loads late.	Treat it as information only. It is never a reason to delete.
Active`active`	Production calls it above the threshold.	Keep it, and review changes to it with care.

This example shows the partner export from above in a deployment observed for 90 days. Other files still import it and tests cover it, but production recorded no calls during that window. A person checks it before anyone deletes it. To see the raw states of a real capture, open the Fallow Cloud demo.

{
  "file": "src/exports/partner-feed.ts",
  "function": "buildPartnerFeed",
  "line": 42,
  "verdict": "review_required",
  "confidence": "medium",
  "invocations": 0,
  "evidence": {
    "static_status": "used",
    "test_coverage": "covered",
    "v8_tracking": "tracked",
    "observation_days": 90,
    "deployments_observed": 1
  }
}

Illustrative finding with invented values for one deployment. Previous deployments provide separate historical context.

What a team does with the counts.

Before a migration.When a team moves a service to a new framework or database, every function it ports costs time. Sort the code by call count first. Review functions with zero calls in 90 days for removal before you spend time porting them.
In review.Run fallow coverage analyze --cloud, and it lists the functions production calls most. Give changes to those functions to your most careful reviewer.
Cleanup with evidence.Each function on the cleanup list shows its call count and observation window for the selected deployment. The pull request that deletes it can point to that evidence.
Bugs that throw no error.A loop that runs 40 times too often or an import that stopped after a deploy can produce no reported error. The deployment report shows the change in call counts.
Alerts.The dashboard emails organization owners when a service stops reporting, the running commit differs from the deployed commit, coverage drops below a floor you set, or never-called functions exceed a limit. Missing runtime evidence stays separate from tracked functions with zero calls.

Fallow Cloud runs next to your APM tool and your error tracker.

Keep Datadog or New Relic. They watch the health of each host and sample requests to find the slow ones. Sampling is also why they cannot give an exact count per function. A request outside the sample leaves no record, and a function that nobody calls produces no request at all.

Sentry and your page analytics stay too. Sentry records the exceptions your users hit, and page analytics records the pages they open. Fallow Cloud records the call count of each tracked function in each deployment, including functions with zero calls.

A security review can check every field the package sends.

What the package sends.Function names, file paths, line numbers, call counts, the commit, the project id and the environment name.
What it never sends.Arguments, return values, request data or user data.
Source maps, if you upload them.Some builds need source maps to connect a count to your original files. An uploaded source map can contain source code, and uploading one is a separate step your team decides on.
Where the data is kept.Fallow Cloud is hosted in the EU: the API and database run in Amsterdam, and stored files and database backups stay in the EU. The subprocessor list shows which companies handle the data and where.

Fallow Cloud is built on the free Fallow scan.

npx fallow reads the whole repository as one graph and needs no account and no config file. It is open source under MIT, and every static check below is free.

Dead code.Files that nothing imports, exports that no other file uses, and packages in package.json that the code never loads. fallow fix removes unused exports and dependencies, and fallow fix --dry-run shows each change first.
Duplication.Copied blocks across the whole repository, ranked by size, including copies where someone renamed the variables.
Complexity.Functions too complex to change safely, and the files your team changes most.
Circular dependencies.Modules that import each other in a loop. Neither module can move to another package, or be tested, without the other.
Architecture boundaries.Folders that import from folders they should not. How boundaries work
Styling drift.Styles nobody uses, and hardcoded values that skip your design system.
More than 120 framework plugins.Next.js, Nuxt, Vite, Storybook and the other plugins tell Fallow which files a framework loads by convention, and the first run needs no configuration. See the plugin list
Security checks, when you turn them on.Fallow looks for server secrets that end up in client code and for untrusted input that reaches a dangerous call. It ranks each candidate by whether an entry point of your app can reach it, and a person or a coding agent confirms it.

The scan runs in the terminal, in CI, in the editor and in coding agents.

Terminal
npx fallow runs on a laptop with no account and no config file.
CI
fallow audit in GitHub Actions or GitLab CI returns pass, warn or fail for the files a pull request changes, and writes SARIF, JSON and Markdown.
Editor
The VS Code extension, and the Zed and Neovim setups, show findings in the file while someone edits it.
Coding agents
Claude Code, Codex and Cursor call Fallow through its MCP server and see the same findings a reviewer sees before they hand the change back.

In CI, fallow audit fails a pull request only on problems that pull request adds. The findings already in the repository show up next to them and never block a merge. A team with years of old code can turn the gate on the first day and work down the backlog later. The adoption guide covers a large repository or a monorepo step by step.

Try Fallow Cloud on one service for 30 days.

Pick a production service with steady traffic, add the package and deploy. The trial needs no credit card, and after 30 days Fallow Cloud is $20 per seat per month. For an enterprise agreement, email hello@fallow.tools.

Try Fallow Cloud free for 30 days See pricingnpx fallow

Fallow Cloud is analytics for your code.

Connect your code graph to production call counts.

A package in each service counts the calls, and Fallow matches every count to a function.

Add the package to a service

Upload the function list from CI

Match the counts to the list

Read the result where you work