## Background In a different discussion issue (https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/582#note_419571609) it was noted that we tend to favour selecting large services to investigate. One outcome is that it's hard to determine if our performance indicators are useful because there is a long time between updates. We concluded that investigating a smaller service may yield a faster result and give us more information as to if the indicator is useful. ### Incident Data (as at 2020-09-28) |**Date**|**URL**|**Title**|**Notes**| |------------|-----------------------------------------------------------------|--------------------------------------------------|---| | 2020-05-18 | https://gitlab.com/gitlab-com/gl-infra/production/-/issues/2154 | 2020-05-18 Problems reported with mailroom | [Incident review](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/2158) resulted in 3 corrective actions which are all closed. | | 2020-02-10 | https://gitlab.com/gitlab-com/gl-infra/production/-/issues/1641 | 2020-02-10: Unread incoming emails are piling up | Bug was already fixed in a newer version that we were not using.| ## Exit Criteria - [ ] We have an application demand indicator for Service::Mailroom - [ ] We understand recent incidents in this area - [ ] We have answered the question on our goals page: "Do we know how to identify bottlenecks in this service?"