run_health_check
Get a holistic project health score from 0–100 by blending automation stability, coverage, and manual execution, with per-dimension sub-scores to compare specific areas across projects.
Instructions
Get a holistic health assessment for a project: a composite score from 0 to 100 blending automation stability, coverage and manual execution. IMPORTANT: healthScore is NOT comparable BETWEEN projects. The composite weights automation 50 percent, coverage 30 and manual execution 20, then RENORMALISES over whichever of the three actually have data - so a project with no manual executions is scored out of the other two rather than penalised for the gap, and a project holding one test case can score 100 on coverage. A project can therefore outrank another while scoring worse on every dimension the two share. Compare subScores one dimension at a time and say which dimensions each project has. The status label, healthy or warning or critical, is banded straight off that same number and is exactly as incomparable, so do not rank by the word either. Quote healthScore only for one project against itself, and only across calls made with the SAME days and the same include[] - a narrower include[] drops dimensions out of the divisor and moves the score on its own - a wider window can catch work that adds a whole dimension to the renormalisation and move the score with no change in health. One project here scores 20 at 30 days and 21 at 90 purely because two manual executions came into view. The default is 14, so three calls with three windows give three rankings. It returns per-dimension subScores and sections for automation, whose three failure counts mean three different things: failedTests is tests that ENDED failed, consistentlyFailingCount is tests that failed at least three times and NEVER passed in the window, and flakyTestCount is distinct tests that both passed and failed. A test that recovers on retry belongs to the last of those and to none of the others. Its testPassRate counts flaky as a pass, so it is (passedTests + flakyResults) / totalTests, the same formula get_launches_statistics uses, and like that tool it answers null rather than 0 when the window held nothing. This section counts ONLY launches that ended passed or failed, while get_launches_statistics counts every launch in the window, so a launch stored as finished, running, interrupted, timedOut or completed contributes its tests there and not here. The difference between the two totalTests is exactly the tests inside those launches, and it reconciles to the launch: subtract them and the counts match. The rates still agree to about a decimal place because the excluded launches are usually small; the section reports BOTH flaky numbers because they are different units, flakyResults being flaky results and flakyTestCount being DISTINCT tests that both passed and failed over the window, which is what drives the flakiness penalty), testAssets (case and suite counts, status and priority breakdown - both count only cases that HAVE a value, with no residual bucket for the unset ones, so neither is guaranteed to sum to totalCases: in one project here byStatus accounts for 65 of 87 and byPriority for 70), coverage (automation rate and pass-rate trend), manualExecution (pass, fail, blocked, completion) and releases (status counts and active releases). IMPORTANT: days defaults to 14 here while get_launches_trends defaults to 30, so pass the same days to both before comparing their answers. Use include[] to limit which sections are computed. Reach for get_coverage_gaps when you want the specific cases and folders that lack automation rather than one score, and get_feature_scan when the scope is a single Jira issue.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback period for analysis (default: 14 days) | |
| include | No | Which sections to compute. Defaults to all. The composite score uses whichever of automation/coverage/manualExecution are present and have data. | |
| projectId | Yes | Project UUID to assess |