Insights and DORA
Blast radius, change-failure attribution, regression changepoints and the four DORA metrics.
Delivery → Deployments → Insights is deploy history in aggregate.
DORA metrics
| Metric | Measured from |
|---|---|
| Deployment frequency | Deploys per environment per period |
| Lead time for changes | Commit date → production deploy |
| Change failure rate | Deploys followed by an incident or rollback |
| Time to restore | Incident opened → resolved |
Lead time uses commit dates, not merge dates. The clock on a change starts when it was written, and the gap between writing and merging is often the larger half.
Track the trend, not the number. Comparing your change-failure rate to an industry figure tells you nothing; comparing it to your own last quarter tells you whether what you changed worked.
Blast radius
For any deploy: which services depend on what it changed, and how many users were in scope.
Use it before shipping, to decide how carefully to watch — and after, to explain who was affected.
Change-failure attribution
When an incident follows a deploy, the attribution links them — with the changeset, so the post-mortem starts from the actual commits rather than from "something in that release".
Attribution is temporal. It says the incident followed the deploy. It does not say the deploy caused it, and the interface does not imply that it does.
Regression changepoints
A metric that stepped rather than drifted, with the timestamp of the step. Paired with the deploy history, a changepoint that lands within minutes of a release is a strong lead.
This is the aggregate counterpart to level-shift anomaly detection — the same class of problem, at the release scale.
Heatmap and leaderboard
Deploys by hour and by weekday. Most teams discover two things:
- a Friday-afternoon cluster that correlates with the failure rate
- a deploy-free window that is not a policy, just a habit
Annotations
Annotate a deploy with what was learned. Annotations appear on the timeline and in post-mortems, which is how the context survives the people who were there.
The audit ledger
Deploy history is tamper-evident: entries are chained, so a modified or deleted record is detectable.
This matters for compliance, and it matters more for trust — a deploy history that could be quietly edited is not evidence of anything.
Where this behaviour lives: frontend/src/app/deployments/insights/. If the code and this page disagree, the code is right — please fix the page.
Part of Delivery — Deployments, pipelines, releases and everything that ships code.