Certain repositories, ovn/sdn, router, sometimes MCO, are prone to cause disruption regressions. We need to give engineers in these teams better visibility into when they're about to merge something that might break payloads.

We could request /payload on all PRs but this is expensive and a manual task that could still easily be forgotten.

In our epic TRT-787 we will likely soon have a little data on disruption in sippy, enough to know what we expect is normal, and how we're doing the last few days.

This card proposes a similar approach to risk analysis, or actually plugging right into risk analysis. A spyglass panel should be visible with data on disruption:

• backend name
• phase 1 disruption observed (if abnormal)
• phase 2 disruption observed (conformance, if applicable)
• total disruption
• normal disruption over last X period, or fixed limit we've determined
• delta
• risk level, or standard deviations etc

We could then enhance the pr commenter to drop this information right infront of the user if anything looks out of the ordinary.