Convergence latency (deterministic)

Workflow duration across 999 completed run(s) in the window — computed by pr_review_health.sh, not the model.

Run-outcome mix by triggering event

pr-review run conclusions over the window, split by the event that triggered each run — computed deterministically by pr-review-outcomes.sh, not the model. A high cancelled share means runs were evicted while PENDING (concurrency admits one running + one pending per group); a cancelled run is non-blocking but historically rendered as a failing check (#1421).

Sweep hit-rate (deterministic)

How often the pr-review-sweep scheduled backstop actually had to re-review a PR — computed deterministically by pr-review-sweep-metrics.sh, not the model. The scheduled (cron) path re-dispatches only for genuinely un-eventable cases (GitHub-App / cross-repo checks like SonarCloud that emit no workflow_run); the workflow_run fast path handles every eventable case, so a scheduled re-dispatch is always a case the fast path did not cover.

Interpretation: a low rate confirms the timer stays exception-only (the event fast path is carrying the load); a rising rate is a signal that an eventable case is leaking onto the timer — a hole in the narrowing worth investigating.

1. Executive Summary

Status: WARNING
Period: 2026-10-11 16:11Z → 2026-10-12 12:13Z (last 1 day)
Result: 2 of 1000 runs failed (0.2%). Another 302 were cancelled (30.2%).

Key findings:

• Only two hard failures: #102605 (12:07:15Z) and #102601 (11:55:10Z). The "Failed Run Logs" section was empty, so the cause can't be determined from the data given.
• 302 cancellations (30.2%) come in bursts, for example 21:25–21:35Z on 10-11, 17:05–17:40Z on 10-11 and 02:28Z on 10-12. This is most likely concurrency cancel-in-progress on the reusable when check_suite, pull_request and review events arrive together. It is probably benign, but it can't be confirmed without logs.
• About 150 runs were skipped. Skipped runs are normally the reusable's gating/idempotency (for example, non-PR check_suite events). Skips peak in the 18:00–18:45Z window on 10-11.
• Run time is healthy: p50 37s and p95 8m5s. The slowest run took 23m52s, which is an outlier worth watching.

Action required: Pull the logs for runs #102605 and #102601 to identify their cause, and confirm the cancellations come from concurrency grouping.

2. Failure Breakdown

3. Error Patterns

• Failures (#102605, #102601): No log text was provided, so I can't quote an error or name the step or script. I won't guess at a root cause.
  • The two failures are 12 minutes apart and are the only failures of the day. They are likely isolated and not systemic.
  • Both fall in a window where successes continue immediately before and after (#102600, #102602, #102603, #102606), so a persistent break such as a bad pin or an auth failure is unlikely.
• Cancellations: The cancellations cluster within seconds of successful runs, which fits the superseded-run pattern. pr-review-trigger.yml has no concurrency block itself, so any cancel-in-progress behavior would come from pr-review.yml@pr-review/v1-next. I did not see that file, so this is unverified.
• Long-tail duration: The 23m52s maximum is far above the p95 of 8m5s. It may be a deep or security review on a large PR. I can't tell without logs.

4. Token Scope Analysis

• Present (from the workflow permissions block): contents: read, pull-requests: write, checks: read. secrets: inherit passes through the repository and org secrets.
• Missing or insufficient: None evidenced. There are no 401/403 errors, and no gh auth status output was supplied.
• Recommendation: Make no scope changes. If the failed logs show 403s, check actions: read (reading check-run or workflow data) and issues: write (PR comments through the issues API) first.

5. Recommendations

1. [MEDIUM] Run gh run view 102605 --repo petry-projects/.github-private --log-failed, and the same for 102601. Capture the failing step's error, and update the analysis prompt so failed-run logs are actually included. The report can't classify failures without them. Expected impact: the root cause is identified, and the report becomes useful.
2. [LOW] Confirm that the concurrency group in pr-review.yml@pr-review/v1-next is keyed per PR, with cancel-in-progress: true. Expected impact: it confirms the 30% cancellation rate is intentional. If the group is repo-wide, runs for different PRs cancel each other and some PRs miss reviews. The mass cancellations at 21:25–21:35Z need a check that the affected PRs eventually got a successful run.
3. [LOW] Reduce redundant triggers. check_suite: completed fires for every check suite, and together with pull_request and pull_request_review it produces many runs for one PR. Filter early in the reusable, for example with a job-level if on the event, to cut skipped and cancelled runs. Expected impact: lower Actions minute use and less noise. This is beyond the stub's allowed edits, so it has to be done in the reusable.
4. [LOW] Investigate the run that took 23m52s. Check whether it approaches the job timeout-minutes in the reusable. Expected impact: it catches a hang before it turns into a timeout failure.

6. Health Score

Health: 9/10 — The failure rate is 0.2% and run times are healthy. The 30% cancellation rate looks like concurrency churn, but it is unverified, and the two failures can't be diagnosed without logs.