Change failure rate, from deployments that actually happened
Change failure rate is the DORA key most often reported as something else. The usual shortcut is a defect ratio — bugs as a share of completed work — which answers a real question, but not the one DORA asks. DORA asks what share of your deployments caused a problem. 6.34 measures that directly, using the pipeline runs and work-item links Azure DevOps already holds: "N of M sampled deploys failed." The long-standing defect-based number stays exactly where it was, now labelled as the proxy it always was, so nothing you have been tracking moves.
Related: DORA metrics
Two signals have to agree before a deploy is called failed
A single suspicious signal is not evidence. A deploy is only counted as failed when a bug was opened inside its responsibility window AND a later deploy shipped that bug's fix — the pattern that actually looks like "we broke it, then we fixed it." Anything that cannot be attributed with confidence is disclosed on the card rather than quietly counted or quietly dropped, so you can see how much of the window the number is standing on. The "rushed follow-up" threshold calibrates to your own team's median gap between deploys rather than a fixed 24 hours, because a fixed rule convicts nearly every deploy for a team that ships ten times a day. The card tells you which window it used.
It costs you nothing new
This rides the deploy-linked setting and pipeline picker introduced in 6.33: no new setting to find, no new permission to grant, and not a single extra call to Azure DevOps. The pipeline runs and bug dates were already being fetched for lead time and the existing cards — the new number is a join over data that was already on the page. If you enabled deploy-linked lead time in 6.33, change failure rate is simply there.
When the problem is not the numbers
Two messages got honest. If Azure DevOps refuses to return work items, the extension now names the likely cause instead of showing a raw error code: free Stakeholder access cannot read analytics, and the Basic access level is required — along with exactly what to ask your organisation administrator for. And if the GitHub Copilot connection fails — expired token, missing scope, organisation or feature not found, rate limit — the explanation now appears in the language you have chosen. Those messages were hardcoded English in a product that ships six languages, which meant the interface switched to English at precisely the moment you most needed to read it.
A privacy page that says what actually leaves
The in-product Data & Privacy page now states exactly what is sent to Baytek — your organisation ID to confirm your subscription, and usage and error telemetry — alongside everything that never leaves your tenant: work-item content, project and team names, user names and email addresses. It also tells you where to switch usage telemetry off. If your security team reviews extensions, that page is written to be handed to them.
Updating
The update applies automatically when you reopen the extension — nothing to install. The What's New popup shows the highlights once, and change failure rate follows whatever you already decided about deploy-linked measurement, so nothing on your DORA view changes until you say it should. Questions about what a number is telling you? Ask Henry from the top bar — a real person replies within one business day.
Related: Service status