https://grafana-loki.ci.openshift.org/d/ISnBj4LVk/disruption?var-platform=azure&var-percentile=P75&var-backend=openshift-api-new-connections&var-releases=4.15&var-releases=4.14&var-upgrade_type=minor&var-networks=sdn&var-networks=ovn&var-topologies=ha&var-architectures=amd64&var-lookback=1&var-min_disruption_regression=-10&var-min_disruption_job_list=0&var-min_job_runs=10&var-master_nodes_updated=Y&orgId=1&from=now-90d&to=now

Using this graph you can see a defined change in Azure disruption regression around Sep 22. Both 4.14 and 4.15 went from around 1s to 3s for 4.14, and right now more like 5s for 4.15. Changing to the 14 day lookback shows the larger trend more clearly:

https://grafana-loki.ci.openshift.org/d/ISnBj4LVk/disruption?var-platform=azure&var-percentile=P75&var-backend=openshift-api-new-connections&var-releases=4.15&var-releases=4.14&var-upgrade_type=minor&var-networks=sdn&var-networks=ovn&var-topologies=ha&var-architectures=amd64&var-lookback=14&var-min_disruption_regression=-10&var-min_disruption_job_list=0&var-min_job_runs=10&var-master_nodes_updated=Y&orgId=1&from=now-90d&to=now

Use the job list on the first link to find runs to examine. See if we can spot where the extra seconds of disruption are occurring, or find a change that may have done it.

It's possible this is just Azure, so we cannot burn an eternity on this.