Home/Platform/Release risk analytics
Pillar 6 of 6

DORA four keys, decomposed by service and team

An org-wide DORA dashboard hides the thing you need. One team deploying twelve times a day averages away another shipping monthly and breaking production. ArcRelease decomposes the four keys by service and by team, computed from the events it already correlates.

In short

What are release risk analytics?

Release risk analytics are the DORA four keys — deployment frequency, lead time, change failure rate and time to restore — derived from real deployment and incident events rather than a form somebody fills in, and broken out by service and by team so the outlier does not get averaged away.

The problem

Where DORA dashboards mislead.

“

The org average looks fine while one payments service quietly carries all the risk.

“

Change failure rate is a checkbox somebody ticks after the incident review — it measures diligence, not failure.

“

By the time the metric reaches my board pack it describes a quarter I can no longer change.

Release risk analytics

Numbers you can defend when asked where they came from.

Every figure is computed from real events and drills through to the records behind it, because a number you cannot open is a number you cannot use in a QBR.

4 keys
computed from events, not a form — by service and by team
Deployment frequency and lead time counted from real deployment and commit events, not release notes written afterwards.
Change failure rate derived from incident correlation — a deploy counts as a failure when an incident correlates to it and a human confirms it.
Time to restore service reported as its own metric, never conflated with the 10-second time-to-root-cause.
Every tile drills through: a change failure rate opens onto the deployments and correlated incidents behind it.
Decomposed by service and by team, so the team carrying the risk is named rather than averaged away.
How it works

What actually happens.

01

Ingest the events

Deployments from CI and source control, incidents from PagerDuty and Datadog.

02

Correlate and confirm

Incidents are matched to the deploys in their blast radius; confirmed correlations set change failure rate.

03

Decompose

The four keys are broken out by service and by team, with linkage coverage shown for each number.

04

Drill through

Every tile opens onto the underlying deployments and incidents, so a number survives the question "where did that come from".

Who this is for
Engineering LeaderRelease ManagerDevOps / Platform Engineer
Reads from
GitHubGitLabJenkinsPagerDutyDatadog

Metrics resolve to services and releases, not individuals. There is no per-developer leaderboard.

FAQ

Release risk analytics, answered.

They follow the DORA definitions, with the honest caveat that lead time and change failure rate depend on how cleanly work links to deploys. ArcRelease shows the linkage coverage behind each number so you know how much to trust it.

Not by design. Metrics resolve to services and releases, and there is no per-developer leaderboard. Using delivery metrics as a performance ranking produces gamed numbers, so the product deliberately does not make that easy.

No, and ArcRelease keeps them on separate charts. Time to restore is MTTR — diagnosis plus fix plus deploy plus verification. Time to a candidate root cause is how fast you learn what changed.

Related capabilities

Gaja AI preflight
GO, NO-GO or CONDITIONAL, with its reasons attached.
Read more →
Incident correlation
From alert to the pull request that caused it, in about ten seconds.
Read more →

Stop guessing at go/no-go.

Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.

See the platform

Free plan · ten minute setup · we reply in one to two business days