<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=276486) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> I've recently worked on a few issues (most immediately https://gitlab.com/gitlab-org/gitlab/-/issues/225322 and https://gitlab.com/gitlab-org/gitlab/-/issues/15829) where we're changing the nature or application of diff size limits. We're doing this without having a solid picture of the current shape of the impact these limits have on users. We can get at some of this data through trawling through production DBs and making some guesses, but I think a more sustainable, useful way towards making metrics-driven decisions would be to begin tracking how often these limits are reached, creating a dashboard for seeing the trends over time.