Health Metrics
Health metrics describe how a team works: how large its pull requests are, whether they go through review, how long they wait to merge, and whether work happens during working hours.
Each of the five metrics shows a percentage share of work that falls within the accepted norm. On that basis, a single project or team gets one of four health scores, visible on the Overview, on Teams, and in the header of its own page.
The unit of measurement here is a project or a team, never a single person. Health metrics describe the production process, not the contribution of individual participants, and cannot be broken down into individual scores.
Health metrics are in beta. This feature is still being changed and refined, so future releases may change the threshold values, the set of metrics itself, and how the results are presented.
The underlying data stays the same, because the metrics are calculated from the same commits and pull requests as the rest of the statistics in Q247.
Health metrics appear only once an administrator enables them in Configuration, and they require the Enterprise Plugin in version q247-enterprise-plugin-linux-v2.4.2 or newer.
On the Overview, the section is visible to someone with access to the whole project's data, meaning the Manager or Viewer role, and to the manager of a structure branch that covers that project. The Member role, meaning a regular participant, therefore does not see the health section.
On Teams, the section is visible to someone managing at least one team. The full role model is described in Permissions.
Five health metrics
Four of them are calculated from pull requests: Oversize PRs, Unreviewed PR, Stale PRs, and Lightning PRs. The fifth, Overtime Activity, is calculated from events in commits and in documentation, matched against the organization's work calendar.
| Metric | What it shows | Healthy from | Critical below | Minimum sample |
|---|---|---|---|---|
| Oversize PRs | share of pull requests that fall within the size threshold | 90.0% | 85.0% | 5 merged PRs |
| Unreviewed PR | share of pull requests that went through review | 75.0% | 60.0% | 5 merged PRs |
| Stale PRs | share of reviewed pull requests resolved on time | 85.0% | 75.0% | 5 merged PRs |
| Lightning PRs | share of pull requests that were not merged instantly | 85.0% | 75.0% | 5 merged PRs |
| Overtime Activity | share of work done during working hours | 85.0% | 75.0% | 25 events |
A value between the critical threshold and the healthy threshold gives the Watch state. All thresholds are set by an administrator, separately for the whole organization, on the Configuration page.
Oversize PRs
The share of pull requests whose size falls within the threshold. By default, a pull request above 450 Calories is considered oversized.
The metric counts the share of the number of pull requests, so one very large pull request weighs exactly the same as any other pull request over the threshold.
At several hundred changed lines, a reviewer stops reading the change and starts skimming it. Comments then drift toward formatting and naming, and real logic errors get through.
A growing share of oversized pull requests therefore signals a drop in review quality before it shows up in the number of bugs.
An organization may have an increment visibility threshold set, which hides very large increments from charts and statistics. The four metrics calculated from pull requests stay out of its reach, because a pull request is a record of a change's lifecycle, not an increment.
For the size metric this is additionally intentional: the size of the pull request is exactly what is being measured here.
Unreviewed PR
The share of pull requests that went through review before merging, counted among all pull requests merged in the period.
Two things count as evidence of review: a formal review submitted by another person, and a merge performed by someone other than the author. The second case corresponds to the practice where a second person reviews the change and merges it right away, without leaving a formal entry.
A merge performed by the author themself, by their alias, or by a technical account, meaning a bot or a service account, does not count as review.
Review is the last moment when a mistake costs minutes instead of hours. A pull request without it shifts the entire burden of detection onto testing and production, and knowledge of the change stays with one person.
Crediting review through the mere fact of a merge applies only to this metric. Stale PRs and Lightning PRs look at something else, so the same pull request can be reviewed by this metric's standard and still fall into Lightning PRs.
Stale PRs
The share of pull requests resolved within an acceptable time, counted from the moment they were marked ready for review. By default, 2 business days are considered acceptable, to a fraction of a day.
Only pull requests with a formal review, submitted by a reviewer, enter this metric. The identity of the person who merges does not matter here.
A pull request sitting around for a week forces a return to code nobody remembers anymore. The author rebuilds the context from scratch, the reviewer reads a change detached from the decisions that explained it, and the branch drifts away from the main one in the meantime.
Overdue pull requests therefore extend the whole process by more than the waiting time alone would suggest.
The denominator covers every pull request state: open, merged, and closed without a merge. For a pull request that is still open, the time is counted up to the current moment, so a reviewed change that has been sitting for a week already worsens the result now.
Lightning PRs
The share of pull requests that were not merged instantly after being submitted. By default, a merge within 1 minute of being marked ready is considered instant.
The metric looks only at time. The presence of a review and who performs the merge do not matter here, so a pull request that was reviewed but merged within a dozen or so seconds of submission is still counted as instant.
A merge within a few dozen seconds usually means the pull request was created as a formality, and the work reached the main branch without a real look. The metric catches this pattern, which is why its threshold is measured in minutes.
Overtime Activity
The share of events performed during the organization's working hours. Evenings, nights, weekends and holidays all count as outside working hours, all in line with the work calendar.
This one metric does not use pull requests. It draws on events in commits and in documentation, including commits manually restored to statistics and work from branches excluded from scanning, which the remaining views do not show.
Four score states
| State | On the node card | When it occurs |
|---|---|---|
| Healthy | HEALTHY | every scored metric is at or above the healthy threshold |
| Watch | WATCHED | at least one metric is between the critical and the healthy threshold |
| Critical | CRITICAL | at least one metric is below the critical threshold |
| No data | NO DATA | no metric collected the minimum sample |
Node score follows the worst metric
A project or team gets the score of the worst of its scored metrics. Four metrics in the Healthy state and one in the Critical state give the node a Critical score.
This way of calculating makes the aggregate score a signal of where to look. The specific cause is shown only by the individual metric pills in the header of the project's or team's page.
Minimum sample
A metric that has not collected the minimum sample gets no state and does not enter the node score or the aggregate summaries. The four pull-request metrics need 5 merged pull requests, and Overtime Activity needs 25 events.
The sample requirement is fixed for all organizations. An administrator changes the thresholds, but not the minimum sample.
When no metric passes this gate, the node gets the No data state. At the level of a single metric, this state has no pill of its own: a separate card, a position in the summary, and a segment of the distribution bar all concern the whole node.
Up to the threshold of 25 events, every ten documentation events count as one. The threshold of 25 therefore corresponds to 250 events in documentation alone, while commits are counted individually.
Where health is visible
| View | Form |
|---|---|
| Overview | "Project health summary" section, with projects as nodes |
| Teams | "Team health summary" section, with drill-down into the structure |
| Project | Health: {state} pill in the page header |
| Team | Health: {state} pill in the page header |
Pills for individual metrics appear in the header only for metrics in the Watch and Critical states. A project scored Healthy therefore has an empty space next to its health pill, and that is the correct view.
Repositories excluded from measurement
A single repository can be excluded from health metrics on the Sources list. An excluded repository does not enter any of the five metrics, at any level and in any time window, and its project also does not count toward the node count summary.
The exclusion covers health metrics only. The same commits and pull requests in the same period stay visible on the chart, in Workload, in AI Adoption, in project and participant statistics, in the Work Dynamics Indexes, and in Retention.
Threshold changes and historical data
A threshold change made by an administrator also applies to periods before the change, because states are recalculated from scratch at the next recalculation.
The history of scores is not stored separately, so after a threshold is lowered, a project previously scored Critical may show the Watch state for past dates too.
See also
- Health Check thresholds: threshold settings and distribution charts
- Sources: excluding individual repositories
- Work calendar: working hours and holidays
- Calories, Increments and Lines: the unit a pull request's size is measured in