Analytics
How a repository is doing, counted, not guessed
A repository's Analytics tab shows 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 or from the code graph: nothing is estimated, sampled or written by a model.
Agents and people
Who's writing the code
The commits each allowed push brought, and the changes opened, by agents and by people, with each agent on its own. A commit counts once, under the push that first brought it, and history that came by import or fork is no one's. Contributors adds a heatmap of commits by weekday and hour.
Who's writing the code
View as tableCommits
Changes
AgentsPeople
By agent
- claude-code148 commits, 23 changes
- release-bot41 commits, 12 changes
Time to verification
How long changes wait for a person
For agents' changes and people's: from a push to its review being ready, from ready to a person's first look, and from ready to merge, as medians by week. Review load lists the open changes whose review is ready and that no person has looked at yet, the longest waiting first.
Time to verification
View as table| Measure | Agents | People |
|---|---|---|
| Push to review ready | 6 min | 7 min |
| Ready to a person's first look | 3.1 h | 1.4 h |
| Ready to merge | 5.6 h | 2.2 h |
2 changes waiting on a person
From the code graph
Architecture over time
Each day's last build of the default branch is counted from its graph: modules, types, functions, endpoints served, message channels and tables. Coupling hotspots show what's most depended on and what grew, rule health counts the edges each architecture rule matches, and churn shows the modules and endpoints changed most. A dashed line marks a toolchain update, where counts can step without the code changing.
Coupling hotspots
View as tableMost depended on (inbound edges)
| Symbol | Kind | In | Before |
|---|---|---|---|
| InvoiceService | type | 31 | 24 |
| InvoicesController.Get | function | 18 | 12 |
| GET /invoices/{id} | endpoint | 14 | 9 |
| Db.Invoices | table | 12 | 12 |
Pushes, checks and deploys
What the guard refused, and what's flaky
Pushes and merges allowed, denied, or refused because the push guard couldn't be reached, with the commonest reasons and each agent's rejection rate. Each check's pass rate, median and 90th-percentile time, and its flaky runs, which passed after failing on the same commit. Deployments per environment, and the change failure rate.
Push guard outcomes
View as table- Allowed412
- Denied37
- Guard unavailable2
Rejections by agent
- claude-code29 of 214 (14%)
- release-bot3 of 61 (5%)
Traffic
Counted without cookies
Page views, visitors, clones and fetches, and the sites that sent visitors, counted without cookies or a script: a visitor is told apart only within a day, by a hash with a salt kept in memory, and no address is stored. Traffic, review load and each agent's rejections are shown only to people with write access. Each card is in the API too, and agents read them with the MCP tool get_repo_analytics.
Traffic
View as table1,284 views by 316 visitors; 942 clones and fetches by 57 clients.
Counted without cookies: a visitor is told apart only within a day, by a hash of their address and browser kept in memory, and no address is stored. Referrers keep only the site. Visitors are summed by day. Bots aren't counted; clones and fetches count when a pack is sent.
Only people with write access see this card.
See how your repository is doing
Open a repository's Analytics tab, pick 30 days, 90 days or a year, and tick View as table for the numbers.