Thousands (sometimes millions) of data points are running through your repos, code reviews, and pull requests. To manually review these data points for a large code base, a team of more than five engineers, or for a fast growth team would be extremely time-consuming. Gitalytics helps to provide leadership the visibility they need on what's happening with their codebase and team, in an extremely efficient and easy to understand way.

To make our platform even more useful, we want to make sure you're not in it constantly.

Sorry, what?

Yes, we want to make sure you're able to continue with your day outside of Gitalytics, and still get the information you need to keep the engineering team running effectively and happily. That's why we built our custom alerts feature to notify you via Slack, email and other platforms when something unusual happens in your engineering process.

Here are the custom alert types you can create in Gitalytics, and why teams may want to use each of them:

  • Churn
    The percentage of overwritten code over a 3 week time period of it first being written. The reason you may want to monitor a large amount of churn is your team may be struggling with a language or the feature instructions may be unclear and the team is continuously updating the same feature in different ways.

  • Commit Size
    The size of a commit measured by lines of code. Monitoring commit size is useful because it may be a sign that an engineer isn’t committing often enough, or it may be a mistake.

  • Pull Request Age
    The number of days a pull request stays open. Pull requests shouldn’t grow stale, as it will cause other branches, and other team members, to slow down. Pull Request Age alerts let leadership and team members see when pull requests start to get old. This enables easy follow up on the pull request. This age threshold you choose depends on the team and the structure you have, but keep in mind this does not exclude weekends.

  • Pull Request Commenters
    The number of commenters on a pull request. The count should be set as an alert as a large number of commenters may mean the pull request is high risk or contentious. It may need a more senior engineer or leader to review before merging.

  • Pull Request Comments
    The number of comments on a pull request. This should be set as an alert as a large number of comments may mean the pull request is high risk, contentious, or there are disagreements on it. It may need a more senior engineer or leader to review before merging.

  • Pull Request Size
    The size of a pull request measured by lines of code. Large pull requests are a sign that there weren’t frequent enough merges, or that there is a pull request that may require more attention.

  • Retention
    This is the ratio of churned code to new and refactored code. This is an overall measurement on the health of the output by your engineering team. By being alerted to low amounts of retention, leadership and teams can dig into what specifically was causing this, or review processes that could have contributed to the low rate of retention.

If you're unsure how to activate this feature in your Gitalytics account, please reach out to us at

Not a Gitalytics customer yet? Request a free trial through our website, and see your own repositories' metrics from the beginning of their creation.