You track every page view. Now track every function call.

Page analytics stops at the page. Fallow Runtime counts the production calls to each function, per deployment. You and your coding agents see which code works hardest, what changed after a deploy, and where to spend your time.

One page in page analytics, then the functions under that page in Fallow Runtime.
Page analytics sees the page
/checkout	12.4k views
Fallow Runtime sees the code that served it
requireAuth	37k calls	hot
createCheckout	12.4k calls	hot
syncSubscription	1.9k calls	warm
applyGiftCard	14 calls	cold
refundOrderV1	0 calls	not called

The same 30 days, one level deeper. An invented example.

Try Fallow Runtime free for 30 days

or run the free scan first:

npx fallow

The trial needs no credit card. After 30 days it is $20 per seat per month.

Tap a line to see its call count.

Ink lines: how the code connects, as Fallow reads it
Line weight: calls in the last 30 days, counted by Fallow Runtime
Closed station: a function with no calls in those 30 days

The service and its call counts are invented for this example.

GitHub stars: 4,847
npm downloads in the last 30 days: 3.82M

Teams at these companies use Fallow in their public repositories.

Your stack measures everything around the code. Nothing measures the code.

Page analytics tells you where users go. Error tracking tells you what broke. None of them tells you which code did the work, or how that changed after a deploy.

What each tool in a production stack measures
What you measure	Common tools	What it tells you
Servers and services	Datadog, New Relic	host health, plus latency, throughput and errors per endpoint
Errors	Sentry	the exceptions your users hit, with the stack trace
Pages and users	Google Analytics, PostHog, Amplitude	page views, events and funnels, up to the page and no deeper
Your code	Fallow Runtime	the calls to each function in production, per deployment, from hot to not called

The analytics layer your code never had.

Coding agents now write a large part of new code, and developers read less of it line by line. Somebody still has to know how that code behaves in production.

Fallow Runtime gives humans and agents the same facts: how often each function runs, and how that changes with each deployment. Every function gets a place on one scale.

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.

What code analytics looks like at work.

Agents use the counts to check and focus their own work. People use them to decide where to look.

An agent checks its change before it hands it back.
The agent is about to change applyDiscount. Through the MCP server it learns that production calls the function 412k times a month from 9 callers. It keeps the change small, adds a test, and says why in the pull request.
applyDiscount · 412k calls · 9 callers · high risk
A reviewer reads the 2 functions that matter out of 40.
An agent opened a pull request that changes 40 functions. The reviewer gets the hot paths from Fallow and compares them with the change. Two of the 40 sit on the checkout path, so the reviewer reads those line by line and skims the rest.
2 of 40 changed functions on hot paths
A deployment report finds a bug that threw no error.
After Tuesday's deploy, loadInvoices runs 40 times as often per hour as before, which points to a loop or a retry. importOrders stopped: steady calls before the deploy, none after. No error tracker saw either one.
loadInvoices · heated up 40x · importOrders · stopped
A team plans a migration with the counts.
Before the move to a new framework, the team leaves out the code production has not called in 90 days. It ports the hot code first and tests it hardest.
1,240 functions · 212 not called in 90 days

The functions and the numbers in these examples are invented.

Every deployment gets a report.

The dashboard compares each deployment with the one before it. You see what heated up, what cooled down, what stopped, and which new code has not run yet.

Deployment 4f2a91c

Deployed 2 days ago, compared with 9b07e3d

Heated up: 3
Cooled down: 5
Stopped: 1
New code, not called yet: 2

Function	Before	After	Change
loadInvoicessrc/billing/invoices.ts	Before 120 / h	After 4.8k / h	Heated up
importOrderssrc/orders/import.ts	Before 83 / h	After 0 / h	Stopped
bulkArchivesrc/orders/archive.ts	Before New	After 0 / h	New, not called yet
applyDiscountsrc/checkout/discount.ts	Before 17k / h	After 7.9k / h	Cooled down

An invented example of the deployment report in the dashboard. Calls are per hour, because two deployments run for different lengths of time.

A timeline of every deployment. Each deployment shows its commit, its environment and its coverage, next to the one before it.
Functions sorted by calls. Open a repository and see its hottest functions first, with the file of each one.
The source, marked up. Open a file and see which lines production ran and which it did not.
Email when something goes quiet. The dashboard emails you when a service stops reporting, or when it runs a commit you did not deploy.

How it works.

1
Count. A small package in each production service counts how often each function runs. It counts every call and takes no samples, so a function that runs twice a month shows 2 calls.
2
Match. Fallow matches every count to a function in its graph of your code, and keeps the counts of each deployment apart.
3
Read. People read the result in the dashboard and the CLI. Coding agents read the same result through the MCP server, before they change code and before they hand it back.

The package sends call counts, nothing from your requests.

Function names, file paths, line numbers, call counts, the commit, the project id and the environment name.

Never arguments, return values, request data or user data.

It runs next to your APM tool. The APM samples requests to find slow ones. Fallow Runtime counts every call to each function, so it also sees the rare calls that a sample misses.

Fallow Runtime is hosted in the EU: the API and database run in Amsterdam, and stored files and database backups stay in the EU.

$20 per seat per month, after a 30-day trial.

Twelve seats cost $240 a month. Without a card on file, the trial cannot turn into a charge. Ask us about an enterprise plan.

Fallow Runtime is built on Fallow, the open-source scan for dead, duplicated and overly complex code, which runs in seconds and stays free. Start with npx fallow today.

Start with one service.

Add the package to one production service with steady traffic and deploy. After the first report, you see which of its functions are hot, warm, cold or not called. Your next deploy gets its own report.

Try Fallow Runtime free for 30 daysnpx fallow