I'm seeing this on about 50% of alerts.

This one was really confusing:
https://chromeperf.appspot.com/group_report?sid=c0125b7d62a5dcbb28f5b1fb100ccf991a27cc62e2eaa86965d910589d478fcd

the alerts page says there are 22 alerts, and the group_report page says there are 178.

Upping the priority since it looks like this is causing a lot of separate bugs to be filed on the same group of alerts.

Thanks!
I've added this to the list of core features in go/chromeperf-v2-status.
Let me see if I understand the problem and then I'll try to have a mock to discuss at the services weekly tomorrow?

The V1/alerts page and V2 alerts-section only show untriaged alerts by default. However, there might be relevant triaged alerts that sheriffs need to see in order to triage. For example, bots upload data at different times, so an alert may be created for one bot, then a sheriff may triage it, then another alert for the same timeseries at about the same revision range may be created for another bot. A sheriff should triage the new alert to the same bug as the first alert. In order to do that, they need to be able to see the first alert and its bug. They could show all untriaged alerts, but that's a huge firehose.

Alternatively, the UI could hide untriaged alerts from sheriffs until all of their test suite's bots have caught up to them. However, this would increase the latency between when a regression is committed and when pinpoint can find it.

The V1 UI solves this problem by displaying overlapping triaged alerts in the /group_report page, but V2 doesn't solve this problem yet. One possible solution I've been considering is adding a button like "open overlapping alerts" that would open a new alerts section containing both triaged and untriaged alerts that overlap the combined revision range of selected alerts. This would effectively produce the same alerts table as the V1/group_report page currently provides. However, multiple alerts sections might require users to scroll up and down a lot. While significantly better than opening multiple tabs, a more localized UI might be even better. For example, there might be room for another small column of buttons in the alerts table. These buttons would contain the number of triaged alerts that would be grouped with a given alert or group. When clicked, they display/hide table rows containing the triaged alerts directly underneath the untriaged alert/group, possibly sub-grouped by bug.

Let me know if you have any thoughts, otherwise I'll follow up with you when I have a prototype. Thanks!

Thanks for re-summarizing. You've understood the problem correctly. Let's definitely chat in the services meeting tomorrow!

Please take a look at the prototype: https://v2spa-dot-chromeperf.appspot.com/#sheriff=Chromium_Perf_Sheriff
We can discuss this in the services weekly tomorrow.

I'm OOO so comments will be short, but:

* Overall looks great
* I think the best way to get feedback on it would be to sit with a perf sheriff, but it looks like there aren't any in MTV soon. Maybe ask Mustaq if he'd like to VC and try it out?
* One thing I was surprised by is that even though I was looking for it, my eyes went right past the bug id column. I wonder if there's some visual treatment we could give for it that shows it's triaged already? Either the specific column for bug id, or just the whole row?

Is this a blocker for v2spa, https://bugs.chromium.org/p/chromium/issues/detail?id=918193 ? 

I don't think so. I think this code was all server-side, and when I last touched it, was completely independent of v2 spa.

I added a "Triaged" column to the alerts table containing an expand-button that displays triaged alerts alongside untriaged alerts. I received positive feedback about it, so I'll close this bug. When v2spa is closer to launching, I'll see if it needs more polish, and file separate bugs as necessary.