Analytics

A repository's Analytics tab, between Activity and Settings, shows how it's doing over time: what its code is made of, who is writing it, how pushes, checks and deployments go, and how long changes wait to be verified. Every number is counted from what Branchscope recorded (pushes, checks, deployments, changes and reviews) or from the code graph; nothing is estimated, sampled or written by a model.

Reading the page#

• Range: 30 days, 90 days (the default) or 1 year, in whole UTC days up to today. Weeks start on Monday.
• Cards: each card is a chart with the same numbers as a table: tick View as table to see it, and screen readers always read it. A card says where its data starts ("Data since 3 Oct.") and links to the tab its data comes from.
• Medians and percentiles are values that happened (the middle one, and the one 90% of the others are under), never averaged or interpolated.
• Who sees what: everyone who can read the repository sees every card except three, which need write access: each agent's rejections under push guard outcomes, review load, and traffic.

What each card counts#

Card	What it counts
Languages	Bytes per language at the default branch's head, by file extension.
Languages over time	The same, each time the default branch moves to a new commit; the day's last count is a point.
Architecture over time	For the default branch's last build each day: modules, types, functions, endpoints it serves, message channels, tables, mapped entities, nodes and edges, counted from its graph. A dashed line marks a toolchain update, where counts can step without the code changing.
Coupling hotspots	At the range's last build: the functions and types with the most inbound and outbound edges, and those whose inbound edges grew most since the range's first build (among the 100 most depended on at both). Each opens on the Graph tab.
Rule health	The edges matching each architecture rule at each day's last build, against that build's own branchscope.json.
Churn by graph node	The modules and endpoints changed by the most default-branch builds, each build compared with the head before it by the graph diff. Edits inside a body aren't graph changes; builds of another toolchain aren't compared.
Repositories that depend on this one	Your other repositories whose default branch calls an endpoint this one serves or subscribes to a channel it publishes, from the connection index now. Those you can't read are only a count.
Who's writing the code	Commits each allowed push brought, and changes opened, by agents and by people. A commit counts once, under the push that first brought it: a merge counts its merge commit, a branch pushed again counts nothing.
Push guard outcomes	Pushes and merges allowed, denied, and refused because the guard couldn't be reached; the commonest reasons for denials (the ruleset, or the message); each agent's rejection rate. Why the guard couldn't be reached isn't recorded.
Time to verification	For agents' and people's changes: a push to its review being ready; ready to a person's first look (opening the review here, or a comment, approval or merge by a person after it was ready); ready to merge.
Review load	Open changes, not drafts, whose latest review is ready and that no person has looked at yet, the longest waiting first; and who has been merging, commenting and approving. Changes have no assigned reviewers.
Runs and checks	Each check's runs, pass rate, median and 90th-percentile time, and flaky runs (passed after failing on the same commit); minutes of workflow jobs.
Deploys	Deployments per week and environment; the change failure rate: deployments that failed or were rolled back (the next deployment there brought back a commit deployed before) over all of them.
Throughput	Changes opened, merged and closed unmerged per week, and merged changes' size in lines and in graph nodes touched (those reviewed).
Contributors	People and agents by the commits their pushes brought, and a heatmap of those commits by weekday and hour (UTC) of the push.
Traffic	Page views and visitors, clones and fetches and who to, and the sites that sent visitors.

Where data starts#

Counting started when Analytics was deployed. Push guard outcomes, checks, deploys, throughput and authorship were counted again from what was already recorded, and the default branch's last 200 builds whose graphs were still stored were counted. Languages over time, first looks at reviews and traffic start empty. History that came by import or fork is not counted as anyone's commits. Rollups are kept two years, traffic one.

Traffic and privacy#

Traffic is counted without cookies or a script, and no address is stored:

• Views are counted when one of the repository's pages is shown; bots (by their user agent) aren't counted.
• Visitors are told apart only within a day, by a hash of the address and browser with a salt that's made each day and kept in memory; when the day ends, the salt and the hashes are gone. Only the day's counts are stored, so a range's visitors are its days' added up.
• Referrers keep only the site's name.
• Clones and fetches count when the git service sends a pack, over HTTPS or SSH; a push, or looking at the refs alone, isn't one.

API and MCP#

Each card is GET /repos/{owner}/{name}/analytics/{section}?range=30d|90d|1y in the API, with the repository's own rights: languages, language-history, architecture, hotspots, rules, churn, dependents, authorship, pushes, verification, review-load, checks, deploys, throughput, contributors and traffic. Agents read them with the MCP tool get_repo_analytics.