Weekly engineering health reports: what to track, what to ignore

Engineering health metrics tend toward two failure modes: too lagging (quarterly OKRs that describe history, not current state) or too noisy (real-time dashboards that nobody looks at because there’s too much to interpret without a dedicated sitting). A weekly cadence avoids both traps.

A well-designed weekly engineering health report answers one question: is your team in a better or worse position to ship this week than last week? Everything else is detail.

The five metrics worth tracking weekly

Friction Score (0–100) — a composite of CI failure rate, stale PR count, deploy failure rate, and flaky test signals, weighted by severity. The trend line matters more than the absolute number.
Hours saved by automation — how much time did your automation rules save this week? This is the ROI number for tooling spend and the signal that your automation coverage is working.
Main branch CI pass rate — what percentage of CI runs on main passed on first attempt? Below 85% is a reliability problem worth addressing explicitly.
Stale PR count — how many open PRs have been without review activity for more than 48 hours? This is your review culture health metric.
Critical signal count — how many critical-severity events (main branch failures, production deploy failures) occurred this week? Zero is the target.

What not to track weekly

Certain metrics are valuable but wrong for a weekly cadence:

Deployment frequency — meaningful as a monthly trend, noisy week-to-week due to sprint end clustering.
Individual developer metrics — PR count per engineer, commit frequency per engineer. These belong in 1:1 coaching conversations, not health reports that go to the whole team.
Test coverage percentage — changes too slowly to be informative weekly. Review quarterly.

The right audience for each metric

Not every metric belongs in front of every stakeholder. The Friction Score and critical signal count are appropriate for engineering leadership and cross-functional status updates. Hours saved and main branch pass rate are operational metrics for the engineering team. Stale PR count is a team-level metric that belongs in sprint retrospectives.

How Deviera’s Weekly Health Report works

Deviera generates the weekly health report automatically for Pro and higher plans. Every Monday at 9am UTC, the report is computed from the last 7 days of signal activity: total signals, critical count, hours saved, Friction Score, stale PR count, and top friction sources by repository. It’s delivered by email and available in the dashboard.

The top friction sources section is the most actionable part: it shows which repositories are generating the most signals, which almost always corresponds to where your CI investment or review process needs attention. Teams that act on that list systematically reduce their Friction Score within 4–6 weeks.

Building your own if you’re not yet using tooling

At minimum, spend 15 minutes each Monday reviewing: how many CI failures hit main last week, how many PRs sat unreviewed for more than 2 days, and whether any deploy failures went untracked. Write down the numbers. After 4 weeks, you’ll have a baseline. After 8 weeks, you’ll have a trend. That trend is what turns reactive engineering management into proactive engineering management.