Your goal should be to catch issues like the RDS hang in a scoped group of computers. The RDS failure shows up as a service that restarts or never reaches running, and the USB audio one shows up as a driver load failing or a device arrival event with no matching audio session. Both are visible in ETW (Microsoft-Windows-Kernel-Process, Kernel-PnP, TerminalServices providers) within minutes of the reboot. ET Ducky has custom behavior detection by reading kernel logs and can be configured to look for things like this. You'd tag hosts for your alpha group and schedule that tag to receive the updates before any others, then regressions in the scope for your custom behavior rule would trigger an alert that you could address before the next update ring was deployed. I build ET Ducky and that is how we mark a patch as successful. If there are issues in an early deployment ring you can pause the deployment.