The drift that never made it to the retro
How a team stopped arguing about whether delivery "feels slower" — because the four DORA numbers were already computed, banded, and pointing at the exact pull requests to blame.
TUESDAY, 10:04 — SPRINT PLANNING
Velocity looks fine. The board is green. But lead time has been creeping for two weeks — 26 hours to 41 — spread across three tools nobody aggregates. The retro that might catch it is three sprints away, and it will run on anecdotes.
TUESDAY, 09:00 — #ENG-HEALTH
The drift alert landed before planning even started: "Lead time for changes: 41h, up 58% over 14 days — band High → Medium," with the three pull requests dragging the average linked. The conversation is about the fix, not the feeling.
Nobody added a process. The pipeline just started keeping score.
Before the numbers, there was "it feels slower"
If you run more than one delivery team, you already know this meeting:
- The data lived in three tools. Deployments in CI, lead time in Git, incidents in Jira — real numbers everywhere, a shared number nowhere.
- Performance conversations ran on anecdotes. "It feels slower lately" versus "we're fine" — and whoever spoke with more confidence won.
- Drift surfaced at the quarterly review — by which time the slowdown was baked into two releases and nobody remembered which change started it.
- The tools that did measure it wanted to rank developers. A non-starter for the team — and for the works council.
So the four numbers stopped being a quarterly argument and became an hourly evaluation.
The guided tour — from raw events to a number you can interrogate
Connect the stack you already have
Jira, GitHub, GitLab, Linear, Azure DevOps and Jenkins connect in minutes — webhook or polling, no agents, no workflow changes for developers. Historical activity backfills your first baseline within the hour, not after a quarter of data collection.
Four numbers, computed the same way for every team
Deployment frequency, lead time for changes, change failure rate, time to restore — scored hourly and banded Elite to Low against DORA research benchmarks and your own trailing average. The same math on every team, so a comparison means something.
Drift alerts that name the culprits
When a metric degrades past your threshold, the alert lands in Slack or Teams — with the exact pull requests and issues dragging the average linked, not just a number that went red. The fix conversation starts the same morning.
Team-level by design — and gates when it matters
Every number drills down to work items, never to people: there is no per-developer view, deliberately. And when a release shouldn't ship while delivery health is degraded, a readiness gate can hold it until the band recovers.
Per-developer scorecards: not built. Not on the roadmap either.
The same retro, one quarter later
Before
- —Drift surfaced at the quarterly review — two releases too late
- —"It feels slower" vs. "we're fine" — confidence won, not data
- —Baseline was folklore: "normal for us" meant whatever the loudest person remembered
- —Metrics tooling stalled on developer-surveillance fears
After
- ✓Drift lands in Slack the week it starts, culprit PRs attached
- ✓41h, up 58%, these three PRs — the argument is over the fix
- ✓Elite/High/Medium/Low banding against DORA research and your own trailing average
- ✓Team-level only, by design — nothing for the works council to veto
An honest fit check
This fits if
- ✓Your delivery runs through Jira + GitHub, GitLab, Linear or Azure DevOps
- ✓You have more than one team and no shared delivery number
- ✓Leadership asks "are we getting faster or slower?" and the honest answer is a shrug
- ✓You want DORA metrics without building a data pipeline to get them
And honestly, if
- ·You want individual developer rankings — deliberately not built, and it won't be. DORA measures flow through a system, not people.
- ·You don't merge through PRs or deploy through CI — there's nothing to measure from.
- ·You're here for the EU's DORA regulation — that's the Digital Operational Resilience Act, a financial-sector law, and a different thing entirely. Our GDPR and EU AI Act pages cover the compliance side.
A second opinion on your delivery metrics
A senior engineering lead reviews your team's metrics and gives a verdict per metric. This is an engineering review, not a legal review.
How Expert Review works →DORA metrics FAQ
Which DORA metrics does PulseCheck track, and how are they computed?
All four: deployment frequency, lead time for changes, change failure rate, and time to restore. They are computed from your actual delivery events — merges, deployments, incident issues — refreshed hourly, with the computation identical across every team.
Which tools feed the metrics?
Jira, GitHub, GitLab, Linear, Azure DevOps and Jenkins. Most teams connect two sources in under ten minutes; historical backfill produces a usable baseline the same day.
Is this related to the EU's DORA regulation?
No — this page is about DORA delivery metrics (DevOps Research & Assessment): deployment frequency, lead time, change failure rate and time to restore. The EU's Digital Operational Resilience Act is a financial-sector regulation and a different thing entirely. PulseCheck's compliance features live on our GDPR and EU AI Act solution pages.
How is this different from other DORA tools?
PulseCheck pairs the four metrics with compliance monitoring and engineering-investment analytics in one platform — and every metric drills down to the underlying pull requests and issues, so it's a number you can interrogate, not a scorecard you have to trust. Expert Review adds an engineering review by a senior engineering lead (not a legal review).
Can it be used to track individual developers?
No, by design. Metrics are computed and displayed at team level only. That boundary is what keeps DORA useful — the research is about flow through a system, not individual output.