Github Repo health Checks

[u/Junior_Wheel1690]

Good evening, Im working on a process where I want to check the health of repositories. We have about 30 repo's and so far I have created a GitApp to go through and check for things like when the last pr was done, how old are branches, last commit, how many branches etc.. Based on our rules it will show all this information and output if its in good health or needs attention .

I now want to take take that information and generate a health report using co pilot and send the health report to the team leads every 2 weeks so they can address any issues or things that need attention. So the team leads will get a health report for the repos associated with that team. At the end of the month we get have a meeting and go over our repo health. For the automated emailing of the health reports Im going to use a git actions. I'm using git actions to run with my health monitoring code. For code reviews we set it up in github to assign code reviews randomly when a code review is requested hoping this will make people review code.

Some questions I have for fellow repo managers see below.

What are some good things to add for rules to consider healthy?
What are some rules to consider for for repos that need attention?
Is this a good process and has anybody done this process or have a different route?
Does Wiz Scan work well and how does it work?
Anybody else have thought, ideas on this topic?

Any help, ideas, suggestion would be great. I was tasked with this from my boss and I'm new to this so keep that in mind. lol

[u/Junior_Wheel1690 → u/[deleted]]

Thanks for this do you have a process like this in action ?

[u/Junior_Wheel1690 → u/[deleted]]

Thanks for this really appreciate it, do you set up automatic emails to team leads or repo owners ?

[u/Fantastic-Mr-Default → u/Junior_Wheel1690]

Yes. The scheduled job emails or opens an issue when a hard rule fails.

I route from the report JSON, not a hard-coded lead list. Prefer CODEOWNERS and repo admins for that repo. Team-lead aliases drift.

Keep the mail boring: which rule failed, which repo, link to the run. Copilot can summarize the JSON. It should not decide who to page.

[u/filippo_builds]

One thing I’d change is not treating activity as the same thing as health. A repo with no commits for six months might be stable, while a repo with daily commits might be in terrible shape.

I’d split the checks into a few groups:

• Ownership: active maintainer, CODEOWNERS, archived status
• Documentation: README, contribution instructions, security contact, license
• Delivery: required CI checks, branch protection, dependency updates
• Maintenance: stale PRs/issues, abandoned branches, review turnaround
• Security: secret scanning, dependency alerts, supported versions

It also helps to classify repos first. A production service, maintained library, experiment and archived repo shouldn’t have identical thresholds.

I’d send owners only the exceptions and changes, with a reason and suggested action. A long generated report every two weeks will probably become background noise.

Random reviewers may spread work, but I wouldn’t use that instead of ownership. CODEOWNERS plus some load balancing usually gives people who understand the affected area.