Outcomes & metrics
Business value makes the case in outcomes; this page makes those outcomes measurable. It lists the KPIs DevsPortal is designed to move, how to measure each one honestly, and a baseline-then-measure discipline so you can attribute change to the platform rather than to wishful thinking.
Baseline before you roll out. Capture each metric's current value before the pilot, pick a small number of targets, and re-measure on a fixed cadence. A platform that "feels faster" is unconvincing to a CFO; a lead-time chart that dropped from 8 days to 2 is not.
The KPIs at a glance
| KPI | What it tells you | Typical direction with DevsPortal |
|---|---|---|
| Developer onboarding time | How fast a new engineer reaches their first production deploy | Down (golden paths replace tribal knowledge) |
| Lead time for changes (DORA) | Commit → running in production | Down (self-service deploy + promotion) |
| Deployment frequency (DORA) | How often you ship | Up (low-friction, self-service delivery) |
| Change-failure rate (DORA) | % of deploys causing a failure | Down (immutable releases + enforced golden paths) |
| MTTR (DORA) | Time to restore service after an incident | Down (built-in, context-rich observability) |
| Infra & ops cost | Spend + toil to run the delivery stack | Down (one platform vs. stitched tools) |
| % services on golden paths | Standardization coverage | Up (the leading indicator) |
| Time to stand up a new team | Org-scaling speed | Down (self-service tenancy) |
Developer onboarding time
Definition: elapsed time from a new developer's day one to their first successful deploy to a non-prod environment (and, separately, to prod).
How to measure: record the date a developer joins a team and the timestamp of their first deploy through the portal. Track the median across recent hires.
Why DevsPortal moves it: golden-path templates and a self-service portal replace "learn our bespoke setup from a senior engineer." Onboarding becomes "pick a template, deploy" instead of weeks of shadowing.
Lead time for changes (DORA)
Definition: median time from code commit to that change running in production.
How to measure: instrument your CI/git events and the platform's deployment events; measure commit timestamp → production deploy timestamp. The platform's immutable releases and promotion pipeline give you clean deploy events to anchor on.
Why DevsPortal moves it: self-service build/deploy and one-click promotion across environments remove the hand-offs and ticket queues that dominate lead time.
Deployment frequency (DORA)
Definition: how often the organization (or a team) deploys to production.
How to measure: count production deploys per team per week/month from the platform's deployment events. Watch the trend, not a single number.
Why DevsPortal moves it: when deploying is a low-risk, self-service action, batching shrinks — teams ship smaller changes more often, which is itself a quality signal.
Change-failure rate (DORA)
Definition: the percentage of production deploys that result in a failure requiring remediation (rollback, hotfix, incident).
How to measure: track deploys that triggered a rollback or incident over total deploys. Use the platform's release history (each promotion is a discrete, identifiable release).
Why DevsPortal moves it: immutable releases mean what was tested is exactly what ships (no drift between environments), and enforced golden paths keep risky configurations out by construction. Both reduce failure rate.
MTTR (DORA)
Definition: median time to restore service after a production incident.
How to measure: incident start → service restored, from your incident tooling. Pair it with how quickly responders located the cause.
Why DevsPortal moves it: observability is built in and automatically scoped to project/component/environment, so responders debug from the same place they deployed — shortening the "where do I even look" phase. Rolling back is re-pointing to a known-good immutable release.
Infrastructure & operations cost
Definition: the total cost to run the delivery platform — infrastructure spend plus the engineering toil to keep it alive.
How to measure: sum the cluster/infrastructure cost attributable to the platform, plus an estimate of platform-team hours spent on toil (integrating, patching, firefighting the toolchain). Compare to the pre-DevsPortal baseline of separately run tools.
Why DevsPortal moves it: one integrated platform replaces a stitched-together set of separately licensed and maintained tools; the reference footprint runs all planes plus registry, identity, secrets, and observability on a single cluster. See Build vs buy for the cost detail.
Percent of services on golden paths
Definition: the share of services deployed through platform-authored golden paths (ComponentTypes/templates) versus bespoke, one-off configurations.
How to measure: count components that use a sanctioned ComponentType over total components. The platform makes this directly queryable — every component references its type.
Why it's the leading indicator: this is the metric that predicts the others. Standardization coverage rising is what drives velocity up and failure rate down. Watch it first; the DORA improvements tend to follow it.
Time to stand up a new team
Definition: elapsed time from "a new team exists" to "that team can self-serve deploys in an isolated tenant."
How to measure: record the date a team is created and the date its first member deploys in its own Project/namespace.
Why DevsPortal moves it: projects are self-service, isolated cells with RBAC and network policy applied by the platform — so onboarding a team is configuration, not a multi-week infrastructure project.
A baseline-then-measure approach
- Pick 3-4 KPIs that matter to your sponsor. Don't instrument all eight at once — typically onboarding time, lead time, change-failure rate, and % on golden paths.
- Baseline them before the pilot. Capture current values for the pilot team(s) so you have a credible "before."
- Set targets, not just hopes. e.g. "halve onboarding time," "double deployment frequency for the pilot team."
- Re-measure on a cadence (e.g. monthly) and report the trend alongside the adoption phase you're in — expect leading indicators (% on golden paths) to move before lagging ones (MTTR).
- Attribute carefully. Note confounders (team changes, incidents) so the numbers stay honest. A credible, qualified result beats an inflated one.
The point isn't to win an argument with metrics — it's to know, with evidence, whether the platform is delivering the business value it promised, and to course-correct if a phase isn't landing.