We don’t have quantifiable metrics, but I could distill our habits into some qualitative ones: First, we hotfix only for data loss bugs or for breakage of one

We don’t have quantifiable metrics, but I could distill our habits into some qualitative ones: First, we hotfix only for data loss bugs or for breakage of one of 3-5 absolutely central pieces of functionality without which our site might as well not exist. Anything else goes through the usual testing and deployment cycle, even if we try to accelerate said cycle a bit. To qualify for a hotfix, a bug (other than data loss) has to make the functional area unusable or pointless for a substantial percentage of users (off the top of my head, we’d probably start panicking around 20%). There can’t be a workaround or the workaround has to be so non-obvious our users would be unable to use the site without customer service help. In 3 years here, we’ve deployed a lot of major bugs that were fixed within the hour - that probably happens once every week or two. Nearly allf those fixes passed acceptance testing and cursory code review but not all wait for CI. A handful or two of those may have even met the hotfix criteria above. But I can only think of one or two true hotfixes where we skipped any sort of QA process or proper merge procedure - and those were cases where the site never came up properly at all after the deployment, so they were essentially failed releases. The ones I can think of were production-only configuration errors, where breakage was massive and testing in a staging or CI environment wouldn’t have accomplished anything.