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 the counts of each deployment apart, 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.

Your tools see requests, errors and pages. None of them sees the code.

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.

The tools in a production stack cannot close that gap either. Page analytics counts visits to each page and stops there. An APM tool samples requests, and a call that happens twice a month may never land in a sample. An error tracker records only code that throws. None of them gives a count per function, and none of them compares one deployment with the next.

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 puts the call counts on that list for the same commit. A function that never ran gets a zero instead of dropping out. 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.

Every function gets a place 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. Leave it out of the next migration, or delete it.

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

The dashboard compares calls per hour, because two deployments run for different lengths of time. It flags four kinds of change.

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 deployment before, and has not called it since. When no error fired, this is often the first sign of a bug.
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 of a repository tell an agent which code carries the product. It spends its effort there and leaves code that nobody calls alone.
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 read the same counts from the same deployment, so they argue about the change, not about the facts.

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. No file imports it and production never called it.
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 finding is the partner export from above. Other files still import it, the tests still cover it, and production called it zero times in 90 days across 31 deployments. 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": 31
  }
}

Example output with invented values.

What a team does with the counts.

Before a migration.When a team moves a service to a new framework or a new database, every function it ports costs time. Sort the code by call count first. What production has not called in 90 days gets deleted, and nobody spends a sprint porting it.
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, the window and the number of deployments that window covered. The pull request that deletes it can point to those numbers.
Bugs that throw no error.A loop that runs 40 times too often, or an import that stopped after a deploy, never reaches an error tracker. The deployment report shows both as a change in the counts.
Alerts.The dashboard emails the owners of your organization when a service stops reporting, when the running commit is not the one you deployed, when the share of functions production calls drops below a floor you set, or when the number of never-called functions passes a limit. Without the first alert, a broken deploy would look like an unused feature, because both show 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 function in each deployment, zeros included, and no other tool keeps that number.

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.

Your tools see requests, errors and pages. None of them sees the code.

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