This is the second post in our DRIVE Deep Dive series. Over the coming weeks we're examining each pillar of the DRIVE framework in turn, and mapping DRIVE against the frameworks engineering leaders already run on, including DORA and SPACE. For the complete model, download the full DRIVE framework. Our last post covered Delivery. Up next: Initiatives.
---
AI has removed the last real constraint on producing code, and organizations are shipping more of it than ever. In Cortex's 2026 Engineering Benchmark Report, pull request volume was up 20% year over year, while incidents per pull request climbed 23.5% and change failure rates rose by roughly 30%. More code is going out, and a larger share of it is failing once it gets there.
That failure rarely shows up on the dashboards most teams watch. Uptime, CPU saturation, and infrastructure latency can all read green while the action a customer actually takes, like the checkout that has to clear or the search that has to return a result, fails.
The Reliability pillar in DRIVE asks whether the organization is keeping the promises it made to its customers. It stays grounded in customer reality rather than internal signals, because passing test suites and uptime graphs can hand an organization a false sense of confidence about a product that isn't working the way its customers expect. Two critical metrics cover that reality from two angles: what could go wrong by contract, and what has already gone wrong.
Curated list of functional SLOs, pass/fail
The first metric is binary. Every curated SLO is passing or failing right now, and DRIVE treats it that way instead of as a rolling compliance percentage. That choice is deliberate. Most organizations report reliability as a single number, something like "we were 98% compliant this month," and that number can stay green while a critical SLO is underwater, because averaged compliance hides the one failure inside the success of everything around it.
The rollup follows from the binary. Worst case wins: any single curated SLO breach turns the team red, then the domain red, all the way up. SLOs are never averaged.
The word "curated" is an important distinction here. Not every SLO in the organization belongs in a leadership review. The ones that do are the SLOs that represent customer commitments. The question DRIVE asks is whether the customer's actual experience is measured directly: the login that needs to go through, the API call that needs to return in time, the upload that needs to finish. If a team's reliability is anchored to uptime and not to the user journeys underneath it, the curation gap is the first thing worth fixing. Everything that isn't a customer commitment can be tracked at the team level, where there's context to evaluate it.
For example, a Checkout team carries three curated SLOs: checkout completion above 99.9%, refund processing within 24 hours, and checkout API p99 latency under 600 milliseconds. The first two are green. The latency SLO has been breaching for three days. By the worst-case rule the team's Reliability cell is red, because the rollup won't let a customer-impacting breach sit hidden inside an average of the two that are fine. What the review asks next is the useful part: why has this been red for three days, and what's the action item to close it.
Sev0 and Sev1 incident count
A good way to open the incident discussion is with a two-part question: how many Sev0s did you have last quarter, and how many of them led to a change in your SLO definitions? Most leaders answer the first half immediately and have to look up the second.
An incident is a forced investment. When an outage happens, the business has already paid for it in lost revenue and customer trust, and the only way to recover any of that payment is to extract the learning the incident makes available. Four Sev0s last quarter that produced no change to a single SLO definition is four investments written off. That is also why DRIVE-style reviews are blameless and why incident readouts get dedicated time on the agenda.
The metric itself is the sum of Sev0 and Sev1 counts in the review window, with a month-over-month delta on Sev1. A Sev0 turns the cell red whenever the count is above zero, because a Sev0 warrants leadership attention by definition. Sev1 turns red when it trends up.
Tracking incidents next to SLOs also keeps both honest. If every SLO in a domain is green and a Sev0 still happened, the SLOs are almost certainly not capturing the dimension of customer impact that actually mattered. The review is the right place to flag that and rescope, rather than carry a set of SLOs that reads green through the next outage.
Secondary drag metrics
Once the two critical signals are stable, the review shifts from "are we red anywhere" to "why were we red, and how badly did it hurt." A handful of secondary “drag metrics” can now be folded in. They describe the friction and unrecovered cost that surface after a Reliability event.
MTTR by severity tier explains how painful each break was once it happened.
Change failure rate separates incidents that came from a deploy from those that came from drift.
Error budget burn rate flags teams spending faster than 1x.
SLO coverage, the percentage of Tier 1 services that actually have defined functional SLOs.
Most leaders assume their critical services are covered because the dashboard is green, when in practice many organizations have curated SLOs on a third to half of their Tier 1 services and nothing on the rest. That green dashboard is partial reliability information presented as complete. If a leader is enthusiastic about the SLO dashboard but can't say what share of Tier 1 services are actually covered, that unknown is the first thing to close.
MTTR deserves a specific note, because plenty of teams treat it as their primary reliability metric. It's a useful one, and it answers a real question about how quickly the organization recovers. But it answers that question after the fact. DRIVE leads with what is currently broken and what has already broken, which is to say SLO status and Sev0/Sev1 count, and treats recovery speed as the drill-down that explains how much a break cost. Lead with customer impact; drill into recovery second.
Where existing frameworks fit
Two of DORA's key signals live in this pillar. The Delivery post covered deploy frequency and lead time for changes; while change failure rate and time to restore service sit among the Reliability drag metrics.
For teams that haven't defined customer-facing SLOs yet, the four golden signals from Google's SRE practice, latency, traffic, errors, and saturation, are a defensible starting set, with error budgets layered on as coverage matures. The point of Reliability isn't to swap out the SRE work an organization already does or the incident tooling it already runs. What they’re missing on their own is a recurring, resourced decision about what to do with what they surface. That's the layer DRIVE adds: the cadence that turns SLO status and incident counts into leadership attention and reallocated time.
Measuring Reliability in an OpEx review
In the Operational Excellence review, Reliability comes down to three things.
Which curated SLO is breaching, and why it has stayed red long enough to reach the meeting.
Whether a Sev0 occurred anywhere in the domain, which is treated as a stop-the-line item, not a line item.
Whether the SLO set is actually capturing customer impact at all, using the green-SLOs-with-a-Sev0 case as the trigger to rescope.
None of these ask the review to relitigate the underlying incident data or SLO definitions in real time. The job is narrower: turn a red signal into a named owner and a next action before the meeting ends.
Where the Reliability signals come together
In most organizations, the raw material for these signals is scattered. SLO status lives in an observability tool, incidents live in the pager, and the mapping of which service owns which SLO lives wherever ownership happens to be recorded. Pulling one domain's Reliability picture together for a review usually means someone reconciling all of it by hand beforehand.
Cortex consolidates that work. Scorecards codify SLO coverage as an enforceable standard, so the coverage gap becomes a graded requirement, not an assumption. Cortex pulls SLO status and incident data from the tools that already own them, PagerDuty, Datadog, and the rest, so the review reads one rolled-up picture instead of a manual reconciliation. Engineering Intelligence rolls all of it into the report a domain actually reads at the OpEx review.
Reliability works as part of the recurring review, not as a one-time audit. The DRIVE maturity assessment is a practical place to start, showing where an organization actually stands on this pillar and the other four before committing to a full rollout.
Next in the series: Initiatives, the pillar that asks whether the organization can actually finish the cross-cutting work it starts.
