Daily metrics that cannot drift: subtract yesterday's total
The Daily Metrics automation in the software-factory.dev factory never measures a daily change with a date-filtered query. It subtracts yesterday's cumulative total from today's, a method that cannot drift.
Written by
-
Benedikt Stemmildt Founder & Co-CEO
Published: 3 July 2026 Updated: 2 min read
Most dashboards I have seen drift, and the team cannot say when it started. The Daily Metrics automation in the software factory built in public at software-factory.dev (opens in a new tab) is built to avoid that, and the reason sits in one instruction repeated all the way through its prompt.
This automation is the part that keeps its numbers honest.
A fixed snapshot, once a day
It runs once a day. The trigger is a single cron line, 0 9 * * *, so the snapshot lands at 9am whether anyone is watching or not.
What it does is mechanical on purpose. It runs fixed commands to count lines of code, pull requests, commits, issues, tests, CI health and coverage. It writes the result into a strict JSON file where every field is named in advance. It validates that file against the schema. Then it rebuilds the full time series from every daily snapshot on disk.
The fields are not optional. Even when a count is zero, the field is still there, set to zero. A missing field is treated as a bug, not an empty day.
Deltas come from subtraction, not from date queries
Here is the detail worth copying. The daily change, the delta, is never measured with a date-filtered query. The prompt says so for pull requests and again for commits: do not use a query filtered by date. Compute the delta by subtracting yesterday’s cumulative total from today’s.
Date-filtered queries drift without any warning. Timezones, indexing lag, an issue edited after midnight, and your “merged today” count is off by two with no error fired. Subtracting two cumulative totals cannot drift that way. If yesterday’s number was right and today’s is right, the difference is right.
One method, applied the same way every day
That is the whole idea. A number you can trust does not come from a clever query. It comes from one method, applied the exact same way every day, with the previous day as the anchor.
For a team standing up its own factory, this is the unglamorous part that decides whether the dashboard is worth looking at in six months.
The automation itself: daily-metrics.yaml in the factory’s repository (opens in a new tab).
Which of your team’s daily numbers is computed a slightly different way each time you look?
Further reading
Written by
-
Benedikt Stemmildt · Founder & Co-CEO
Factory skills, part 7 of 18
- A bug-fix automation must never exit quietly The bug-fix automation in the software-factory.dev factory has two ways to end a run: it ships a fix or escalates to a human. Honest failure is a feature you have to design.
- An auto-merging PR reviewer is safe once it knows when to stop The PR Reviewer in the software-factory.dev factory merges code with no human approval. One number makes that safe: it gives up after three failed attempts to fix CI.
Scaling needs named owners
Coding agents scale across teams when named people own the platform, the team practice, the guardrails, and the measurement. Rollout & scale is where that ownership is built and handed to internal owners, in your stack.
Training on this topic: Agentic Engineering for Engineering and Product LeadersWant to check one team first? The self-check: twelve yes or no questions, three minutes, instant result, no account. Take the self-check