We need to document broadly the limits in our application. The limits can be a combination of recommendations or a prevention setting to keep GitLab running in a performant manner. We should start with the obvious ones, it can be a list of areas under Dev which is the most used and expand from there. We need to document what limit, the default, and how to change it. Context: https://gitlab.slack.com/archives/C3MAZRM8W/p1571438653197200 >>> **Sid** 4. Why don’t we add limits to our documentation? https://gitlab.com/gitlab-org/gitlab/merge_requests/18111/diffs Regarding nr. 4 can we make sure that limits in the application are documented? **Sid** Maybe that is an engineering / definition of done responsibility, I’m open to that. **Eric Johnson** We should document the presence of the ability to set limits for sure. But in many cases the limit value itself is dependent on the environment. **Sid** Eric Johnson agree, we should document what limit, the default, and how to change it. And in most cases we should use the default on GitLab.com **Eric Johnson** And maybe the values for our reference environments (first iteration of 25k got certified today) **mek** Sid, agreed. We have started to recommend repo size / sharding limits in our reference architecture. It would be prudent for us to document all the areas in the application as well. I see this as prevention guidelines that would also help availability. I have started an issue to track an MVC effort, starting with Dev section. https://gitlab.com/gitlab-com/www-gitlab-com/issues/5617 **Eric Johnson** It would be brilliant if the values were in code, and could be populated automatically. They’re going to be pretty dynamic (at least GitLab.com’s) **gabriel** perhaps an API for that? >>> ## Dev section (MVC) ### Create stage * Number of comments per notable https://gitlab.com/gitlab-org/gitlab/merge_requests/18111/diffs * TBD ### Plan * TBD ### Manage * TBD