The engineering service reliability targets decision record: why the targets model you chose determines your incident severity calibration and your SLA commitment surface

A 13-person developer tools startup had been building its SaaS product for two years without defining explicit reliability targets in writing. The engineering team shared a cultural understanding that the product should be "highly available" and treated incidents as events requiring urgent response when the system was visibly down and normal troubleshooting when it was not. The CTO had been the primary incident responder for the first fourteen months and had developed a personal calibration for what constituted a severe incident — customer-visible outage requiring all-hands response — versus a moderate incident — degraded performance requiring investigation before the next business day — that the team treated as the shared model by observation, though it had never been written down or explained as a framework.

As the team hired its first three engineers in months fifteen through eighteen, those engineers absorbed the incident response culture by participating in incidents alongside the CTO. The cultural transmission was imperfect in ways that were invisible until an on-call rotation was introduced at month twenty. The two engineers now sharing on-call had each built their severity calibration from different incidents: one had covered an incident where the CTO had escalated quickly on a P1 involving a large customer's report of intermittent failures that turned out to be a misconfigured rate limit; the other had covered an incident where the same CTO had waited for forty-five minutes on a "see if it resolves itself" approach to a slowdown that never appeared in the error rate metrics. Neither engineer had a written model of what distinguished the two incidents' severities. Each had a mental model built from the incidents they had witnessed.

The failure became visible during a Tuesday afternoon incident at month twenty-two. The API's response latency for a subset of requests — specifically requests involving the third-party document parsing service the product used as a backend — began degrading from a median of 180ms to 8-12 seconds. The document parsing operations were still completing; they were just slow. The on-call engineer reviewed the monitoring dashboards: error rate was 0.3% (baseline noise level), server CPU and memory were normal, the third-party service's status page showed no ongoing incidents. From the infrastructure perspective, the system was healthy. The affected customers — specifically the twelve customers whose workflows relied on document parsing operations completing within 2 seconds — were experiencing a product that was functionally unavailable for their use case: batch workflows timed out, user-facing operations appeared to hang, and the customer whose contract included a 2-second response time SLA in a rider was accumulating breach evidence.

The on-call engineer classified the incident as P2 — "significant degradation, investigate before EOD" — and began methodical diagnosis. At the twenty-five minute mark, the CTO joined the incident channel after noticing an email from one of the affected enterprise customers. The CTO's first message was "this is a P1, we need to get everyone on this." The subsequent fifteen minutes were spent not diagnosing the incident but discussing why the classification differed: the on-call engineer had classified P2 because the error rate was below the informal "clearly broken" threshold; the CTO had classified P1 because an enterprise customer had emailed directly. Neither had a written model to reference. The document parsing service's issue was identified at minute forty-seven — a configuration change on the third-party service's side had affected a subset of API tokens — and the fix was applied within eight minutes. The postmortem produced a recommendation to "clarify escalation criteria for incidents with low error rates but high customer impact." The postmortem did not name the structural cause: the team had no reliability target for the document parsing latency that would have made the on-call engineer's P2 classification as clearly incorrect as misreading a thermometer — no threshold that the 8-12 second latency crossed that would have resolved the classification ambiguity without requiring the engineer to judge whether "slow operations" constituted "significant degradation."

A 41-person B2B SaaS had committed to 99.9% monthly uptime in its enterprise sales contracts. The commitment had entered the standard enterprise contract template eighteen months earlier, proposed by the VP of Sales after a competitor's pricing page prominently advertised 99.9% uptime and two enterprise prospects asked whether the company could match it. The VP of Sales had asked the VP of Engineering whether 99.9% uptime was achievable. The VP of Engineering, reviewing the product's uptime over the prior twelve months, found that the infrastructure monitoring had recorded approximately 99.6% uptime — twenty-six hours of downtime over the year, concentrated in four incidents. His response was that 99.9% uptime was aspirational given current performance but not unreachable. The VP of Sales added 99.9% monthly uptime to the enterprise contract template, defined as "the percentage of minutes in a calendar month during which the Service is available," and began including it in contracts. Neither the VP of Sales nor the VP of Engineering defined what "the Service is available" meant in an operational sense — which metrics would be used to calculate the percentage, which layer of the stack would be measured, and which outage categories were excluded.

For the fifteen months following the SLA's adoption, the distinction between "infrastructure available" and "service available" was irrelevant because the product's reliability failures were total failures: database outages, server crashes, deployment failures that took the entire product offline for ten to sixty minutes. The infrastructure health check model — are the servers responding to pings, is the database accepting connections — was an accurate proxy for customer experience availability because the failure modes that actually occurred produced identical readings on both models. The VP of Engineering reported the product's uptime to the board using the infrastructure health check data, the product consistently showed 99.95-99.97% by that measure, and the enterprise SLA commitment looked comfortably achievable.

The divergence emerged in a quarter when the product's payment processing subsystem developed an integration issue with the payment processor the company used for subscription renewals and invoicing. The issue was specific to the payment processor's API: a subset of authentication tokens — specifically tokens issued for accounts created before a schema migration the payment processor had performed three weeks earlier — began returning authentication errors on payment API calls. The engineering team identified the issue within twenty minutes of the first customer report. Resolving it required the payment processor's support team to regenerate tokens for the affected accounts — a process the support team initially estimated at two to four hours.

During the 3.5-hour resolution window, the company's servers were running normally. The database was healthy. The API gateway was serving requests. The infrastructure health check model showed 100% availability throughout the incident. The engineering team's incident response was well-executed: the issue was escalated appropriately, the payment processor was contacted immediately, affected customers were identified within forty-five minutes, and the customer success team notified each affected enterprise customer within ninety minutes of the incident start. By the infrastructure model, the incident was a third-party integration issue with zero minutes of "downtime." By the customer model, any customer attempting to process a payment during the 3.5-hour window received a payment failure error. The VP of Sales received three formal SLA breach notifications from enterprise customers on the first business day after the incident — customers whose legal teams had reviewed the contract language and concluded that "the Service is available" meant "the Service's customer-facing features are available to perform their intended function," not "the Service's servers are running and responding to health checks." The VP of Engineering reviewed the infrastructure monitoring data and prepared a response explaining that the SLA had not been breached under the operational definition of availability the company had been using internally. The legal team spent twelve days working through whether "the Service is available" in the contract was a promise about infrastructure availability or customer operation availability. Two of the three escalating customers accepted a service credit in lieu of a formal breach finding; one required a contract amendment that explicitly defined "Service Availability" to include payment processing operation success rate. The VP of Engineering updated the internal monitoring model, the SLA contract language, and the incident classification criteria in the same week — the first time all three had been reviewed in relation to each other.

A 67-person enterprise SaaS had built what its VP of Engineering considered a mature reliability engineering practice. Services were organized into three tiers based on customer impact: tier-1 services (authentication, billing, the core product API) with an SLO of 99.9% availability and p99 latency under 300ms, measured over rolling twenty-eight-day windows; tier-2 services (reporting, integrations, notifications) with an SLO of 99.5% availability; and tier-3 services (administrative tools, internal analytics pipelines) with no formal SLO. Error budgets were tracked automatically against the tier-1 SLOs; when any tier-1 service exhausted its monthly error budget, a policy required the team owning that service to halt feature work for the remainder of the month and dedicate capacity to reliability improvement. The error budget policy had been invoked twice in eighteen months — once for the authentication service following a configuration deployment incident, once for the billing service following a database connection pool exhaustion — and both times had produced substantive reliability improvements rather than surface-level fixes. The VP of Engineering presented the SLO model at two industry conferences and attributed a 40% reduction in P1 incident frequency to the error budget policy's incentive structure.

The company sold its product in three tiers: Standard (small teams, monthly subscription), Professional (growing organizations, annual subscription), and Enterprise Plus (large organizations, multi-year contracts with custom SLAs). Standard and Professional customers used the product under its standard terms of service, which included an availability commitment worded as commercially reasonable efforts to maintain availability. Enterprise Plus customers had negotiated custom contracts. As the company grew its Enterprise Plus segment from two to eleven customers over eighteen months, the sales team had used the SLO model's success as a selling point — "we have a mature SLO practice and track error budgets against our tier-1 services" — and two Enterprise Plus customers had used this as the basis for requesting a 99.95% availability commitment in their contracts. The VP of Engineering had been consulted on each request during the contract negotiation and had approved both, noting in an internal message that "we've been running above 99.95% on tier-1 services for eight consecutive months, so this should be achievable." The gap between the contractual SLA of 99.95% and the internal SLO target of 99.9% — a gap of 0.05 percentage points — was not noted in either approval discussion. The monthly allowance of downtime under the 99.95% SLA was 21.6 minutes; under the 99.9% SLO it was 43.2 minutes.

The mismatch remained academic for fourteen months. The tier-1 services' actual availability during this period averaged 99.97%, well above both thresholds. The engineering team managed its reliability against the 99.9% SLO; the sales team reported the 99.95% SLA in customer contracts; the two figures were never reviewed against each other because no process existed to compare them. The first quarter the gap became non-academic was a quarter in which the billing service experienced two separate incidents: a forty-five-minute full outage following a failed database schema migration, and a two-hour-and-twenty-minute partial degradation in which the billing service's API was returning intermittent timeouts for a subset of invoice generation requests. The two incidents together produced 165 minutes of impaired service for the two Enterprise Plus customers with 99.95% SLA commitments.

Against the internal SLO of 99.9%, the two incidents consumed 71% of the quarterly error budget — a signal that appropriately triggered the error budget policy and resulted in two weeks of reliability-focused engineering work. The VP of Engineering reported the quarter's reliability data to the engineering team as a near-miss that the error budget policy had caught correctly. Against the 99.95% contractual SLA in the two Enterprise Plus contracts, the same 165 minutes represented a material breach: the monthly SLA allowance was 21.6 minutes, the quarterly allowance was 64.8 minutes, and the two incidents had produced 165 minutes of service impairment. Both affected Enterprise Plus customers submitted SLA breach notifications within two weeks of the quarter close. The legal team, the VP of Engineering, and the VP of Customer Success spent three weeks resolving the breach claims — negotiating service credits, clarifying contractual definitions of "availability" and "downtime," and reviewing whether the partial degradation in the second incident met the contractual definition of impairment. The resolution consumed an estimated forty person-hours across five employees and resulted in service credits totaling approximately $28,000. The VP of Engineering, reviewing how the gap had formed, found that the internal SLO had never been reviewed for alignment with the enterprise contract SLAs — the SLO process was an internal engineering process and the contract SLA was a sales process, and no one had been assigned responsibility for ensuring the two were consistent.

Structural properties set by the engineering service reliability targets decision

Two structural properties are determined by the founding decisions about reliability target definition, measurement scope, severity classification anchoring, SLA derivation, and SLO-SLA alignment. Both are invisible when the system runs at a level of reliability that makes the measurement model's design choices irrelevant; both become visible when the first incident exposes the gap between the model's assumptions and the customer's experience of what available means.

Property 1: Incident severity calibration ceiling. The incident severity calibration ceiling is the maximum consistency and speed with which an engineering organization can classify incident severity at incident onset — the precision of the first severity classification before the full picture of the incident is available, and the alignment between the classification and the customer's experience of the incident's severity. Three factors determine this ceiling. First, target definition model: whether reliability targets are specific enough to anchor the severity classification decision. The first failure story illustrates the absent target failure mode: when the team has no written threshold for what constitutes "below acceptable latency" for a customer-facing operation, the on-call engineer's severity classification is a judgment made against an unwritten standard that varies by engineer. The judgment produces the right answer when the engineer's calibration aligns with the company's calibration — and produces a 15-minute classification debate when it does not. Connect this to the engineering on-call model decision record: the on-call model and the reliability target model are coupled at the severity classification step — the on-call engineer's first decision after detecting an anomaly is whether the anomaly's severity justifies escalation, and that decision is a threshold comparison that requires an explicit threshold to execute consistently regardless of which engineer is on call. Second, measurement scope: whether the SLO measurement covers the customer's experience layer or the infrastructure layer. The second failure story illustrates the measurement scope failure mode: an infrastructure availability model that correctly shows 100% availability during an incident produces a severity classification of "third-party integration issue, no customer impact" at the same time the customer is experiencing payment failures. The measurement scope failure mode is not an infrastructure monitoring failure — the infrastructure monitoring is working correctly; the infrastructure is available. It is a failure to measure the layer where the customer's experience lives. Connect this to the engineering metrics decision record: the reliability metric set and the operational metric set must both be anchored at the customer experience layer to produce consistent severity classifications across the full range of failure modes — a metric set anchored at the infrastructure layer will produce correct classifications for infrastructure failures and incorrect classifications for the class of failures the second failure story illustrates. Third, severity classification model: whether severity tiers are anchored to measurable customer impact thresholds. Both the first and second failure stories illustrate the subjective criteria failure mode: "significant degradation" and "major outage" are categories that require the on-call engineer to judge whether the current state meets the description rather than compare a measured value against a threshold. The difference between anchored and unanchored severity tiers is the difference between a classification that takes thirty seconds and a classification that takes fifteen minutes — and in an incident, fifteen minutes of classification debate is fifteen minutes during which the incident is unresolved and customers are waiting. Connect this to the engineering code review velocity decision record: both the severity classification model and the review risk-tier model share the same structural design requirement — the tier definitions must be anchored to observable, measurable properties that the person making the classification can evaluate quickly at the moment of the decision, without needing to build a full context picture before assigning a tier.

Property 2: SLA commitment surface. The SLA commitment surface is the gap between the organization's customer-facing reliability commitments and the engineering model designed to deliver those commitments — the degree to which SLA commitments are achievable under the engineering team's reliability model, discoverable when the engineering team misses a target, and consistent with the customer's operational interpretation of what "available" means. Three factors determine this surface. First, target derivation model: whether SLA commitments are derived from internal engineering capability or set by sales as competitive comparisons. The second failure story illustrates the sales-led derivation failure mode: the sales team adopts a 99.9% SLA commitment because a competitor advertises it, without a process that connects the commitment to the engineering team's internal reliability measurement. The engineering team's VP gave an informal endorsement based on historical data, but the endorsement was not a commitment that the internal reliability model was calibrated to support the contractual promise — it was an observation that the product had been running above 99.9% for twelve months. The derivation model failure produces an SLA commitment whose achievability is a function of whether historical trends continue rather than whether the engineering model is designed to support the commitment. Connect this to the engineering deployment frequency decision record: the deployment model and the reliability model are coupled at the change failure rate — a deployment model that ships frequent changes increases the probability of reliability incidents, and a reliability model that does not account for the change rate in its SLA calibration will produce SLA commitments that were achievable under the prior deployment cadence and are not achievable after a deployment frequency increase without a corresponding reliability investment. Second, SLA-SLO alignment: whether contractual SLA thresholds are explicitly more lenient than internal SLO targets. The third failure story illustrates the alignment gap failure mode: the SLA commits to 99.95%, the SLO targets 99.9%, and the gap is academic until two incidents produce 165 minutes of downtime against a monthly SLA allowance of 21.6 minutes. The alignment gap failure mode is specifically difficult to detect because it is invisible in the monitoring dashboards and the incident review process — both of which are calibrated to the internal SLO rather than the contractual SLA. The engineering team operates correctly against their model and discovers the contractual breach from the customer's legal team, not from their own monitoring. Connect this to the engineering incident retrospective decision record: the incident retrospective process for the third failure story correctly identified the incidents' technical causes and produced reliability improvements — but would not have identified the SLA-SLO alignment gap without an explicit step in the retrospective process that reviews the incident's impact against not only the internal SLO but the contractual SLA commitments for affected customer tiers. Third, measurement model coherence: whether the SLA measurement definition matches the customer's experience model. The second failure story illustrates the coherence failure mode: "the Service is available" in the contract and "infrastructure health checks pass" in the internal model both describe availability but cover different sets of failure modes. The measurement model coherence failure produces a situation where the engineering team and the customer are both reasoning correctly from their respective models and reaching incompatible conclusions about whether the SLA was breached. Connect this to the engineering technical strategy decision record: a technical strategy that specifies reliability targets needs to specify them at the customer-experience layer rather than the infrastructure layer, because the technical strategy is the basis for the SLA commitments the sales team makes to customers — and a technical strategy that specifies infrastructure availability cannot be used as the basis for a customer SLA that the customer interprets as covering operation availability.

The engineering service reliability targets ADR: five sections

Section 1: Reliability target definition and measurement scope model. The reliability target definition model specifies what the organization is committing to, at which layer, in terms of which customer operations. Three components. Customer-operation coverage: for each customer-facing service, the reliability target is defined in terms of the operations the customer uses the product to perform — not in terms of the infrastructure the product runs on. For an API product, the tier-1 SLO covers the fraction of API requests to customer-facing endpoints that return a non-5xx response within twice the documented response time, measured over a rolling twenty-eight-day window. The scope definition includes an explicit list of what is not covered: health check endpoints, internal service-to-service calls, administrative APIs used only by the engineering team, and operations during declared maintenance windows with advance customer notice. Threshold calibration: the SLO threshold is calibrated to the boundary at which a reasonable customer would consider the product to be failing its implied promise — not to historical performance, not to what competitors advertise. The starting calibration for a customer-facing API is 99.9% of requests to each tier-1 endpoint return a non-5xx response within twice the response time the product's UX is designed to support. The calibration is reviewed quarterly against the incident history: a quarter in which the team successfully met the 99.9% threshold and had no customer complaints about reliability is a signal the threshold is appropriately set; a quarter in which the threshold was met but customers reported reliability concerns indicates the threshold does not cover the failure modes customers are experiencing, and the measurement scope should be expanded. Measurement model documentation: the reliability target is documented in an internal reference document that includes the precise metric definition, the measurement window, the data sources used to calculate the metric, and the exclusion list. The document is reviewed and updated when the product's architecture changes in ways that affect the measurement model — the introduction of a new third-party dependency, the launch of a new customer-facing feature, or a change in the product's response time guarantees. The measurement model documentation is the bridge between the internal SLO and the external SLA: the SLA language in customer contracts references the measurement model documentation to ensure that "the Service is available" in the contract and "99.9% of tier-1 endpoint requests return a non-5xx response within 500ms" in the internal model describe the same thing.

Section 2: Incident severity classification model and customer impact calibration. The severity classification model defines the tier boundaries and the criteria the on-call engineer uses to assign severity at incident onset. Three components. Tier definitions anchored to customer impact thresholds: each severity tier is defined by observable, measurable criteria that the on-call engineer can evaluate from monitoring dashboards within two to three minutes of incident detection. P1: customer-facing error rate above 5% for any tier-1 operation; or any degradation affecting a named Enterprise Plus customer regardless of aggregate breadth; or response latency above twice the SLO threshold for more than three consecutive minutes on any tier-1 endpoint; or any authentication or billing operation failure affecting more than one customer. P2: customer-facing error rate between 1% and 5% for any tier-1 operation; or any degradation that an on-call engineer assesses is likely to reach the P1 threshold without intervention within thirty minutes; or any tier-2 service failure that produces a customer-visible error. P3: any anomaly below the P2 threshold that is confirmed to be customer-visible. The tier definitions are anchored to the SLO: the P1 threshold at 5% error rate is the point where the error budget would exhaust within hours if the incident continues; the P2 threshold at 1% is the point where budget exhaustion within the month becomes likely without improvement. The calibration is explicit, not implicit — the on-call engineer is not asked to judge whether the error rate is "high enough to be significant"; they are asked whether it is above or below 5%. Enterprise customer signal integration: Enterprise Plus customers are enumerated in a reference document accessible to the on-call engineer during the incident. The reference lists each Enterprise Plus customer's tier, their primary customer success contact, and the specific operations the customer depends on most heavily. When the on-call engineer receives a direct customer escalation or identifies a monitoring signal suggesting an Enterprise Plus customer may be affected, the enterprise customer P1 criterion applies regardless of the aggregate impact. The enterprise customer signal integration addresses the first failure story's root cause: the on-call engineer in that story did not classify P1 because the aggregate impact was below their threshold; the enterprise customer had emailed the CTO because no mechanism existed to route an enterprise customer's escalation directly into the severity classification model at incident onset. Escalation and downgrade protocol: the initial severity classification at incident onset is the classification based on the information available within the first three minutes. The on-call engineer classifies and begins the response appropriate for that tier. The severity is updated at each fifteen-minute checkpoint if new information changes the impact picture — a P1 that contains quickly can downgrade to P2 at the first checkpoint; a P2 whose impact grows can escalate to P1. The escalation and downgrade protocol separates the classification decision from the response decision: the engineer classifies at the information available at onset and starts the response appropriate for that classification rather than deferring both while building a complete impact picture.

Section 3: SLA derivation and SLO alignment model. The SLA derivation model defines how external customer commitments relate to internal SLO targets. Three components. SLA derived from SLO, not from competition: every SLA commitment in a customer contract is required to be more lenient than the internal SLO for the services serving that customer tier. The standard buffer is SLA ≤ SLO − 0.05 percentage points. At 99.9% SLO, the maximum contractual SLA is 99.85%. At 99.95% SLO, the maximum contractual SLA is 99.9%. The buffer calibration is reviewed annually against the incident history: if the team has missed the internal SLO target zero times in the past year, the buffer may be reduced; if the team has missed it twice or more, the buffer should be increased. The SLA commitment is set by the VP of Engineering or a designated reliability lead reviewing the internal SLO, not by the sales team reviewing competitor pricing. When the sales team receives a customer request for an SLA above the tier standard, the request is routed to the VP of Engineering with the requested number, the current SLO for the services in scope, and the standard buffer calculation. The VP of Engineering has three options: approve the request if the buffer is preserved, decline the request with an explanation of the current SLO and the buffer requirement, or accept the request with an explicit plan to improve the internal SLO within a named timeline that makes the buffer achievable. Contract review gate: any customer contract with a custom SLA term — above the standard tier SLA — requires engineering sign-off before the contract is executed. The gate is enforced by the legal team's standard contract review process: no contract with a custom SLA executes without an email approval from the VP of Engineering or the designated reliability lead. The gate eliminates the third failure story's root cause: the VP of Engineering approved the 99.95% SLA informally based on recent performance data without noting the gap between the requested SLA and the internal SLO target; the contract review gate would have required the VP to compare the requested SLA against the current SLO and note the gap before the contract executed. SLO revision triggers SLA audit: when the internal SLO for any tier-1 service is revised — downward because the service has been less reliable than the target, or upward because a new customer tier requires a higher commitment — the reliability lead audits the existing customer contracts for SLA terms that may become misaligned under the new SLO. The audit compares each Enterprise Plus customer's SLA term against the new SLO with the standard buffer and flags misalignments for the VP of Engineering and legal team to resolve before the SLO change takes effect. The resolution options are to improve the service reliability to restore the buffer, to renegotiate the contract SLA, or to accept the alignment gap with a named plan to close it within the next two quarters.

Section 4: Error budget model and reliability investment architecture. The error budget model defines how reliability targets translate into engineering investment decisions. Three components. Error budget calculation and tracking: each tier-1 service's monthly error budget is calculated from the SLO target as the fraction of requests the team is allowed to fail within a rolling twenty-eight-day window. At 99.9% SLO with ten million requests per day, the monthly error budget is approximately 288,000 failed requests. The error budget is tracked automatically by the monitoring system and surfaced in a reliability dashboard visible to all engineers. The dashboard shows the current budget consumption as a percentage of the monthly budget, the budget consumption rate over the trailing seven days, and the projected month-end budget consumption at the current rate. Budget exhaustion policy: when any tier-1 service exhausts 80% of its monthly error budget, the team owning that service receives an automatic alert and is required to dedicate at least 20% of their engineering capacity in the following week to reliability investigation — identifying the most significant contributors to budget consumption and implementing fixes. When a tier-1 service exhausts 100% of its monthly error budget, the team halts all feature work for the remainder of the month and dedicates full capacity to reliability improvement. The exhaustion policy is an engineering decision, not a management escalation — the threshold and the response are defined in advance and trigger automatically, so that the response does not require a conversation about whether reliability improvement is worth trading off against feature delivery. Connect this to the engineering sprint planning decision record: the sprint planning model must account for the possibility that the error budget policy triggers during the sprint — a team whose sprint planning model has no mechanism to absorb an error budget policy activation will find the policy conflicting with existing sprint commitments, and the conflict will be resolved informally by whichever stakeholder escalates more urgently rather than by the policy's explicit priority. Connect this to the engineering deployment frequency decision record: the deployment frequency model and the error budget model are coupled at the change failure rate — a deployment model that ships changes frequently generates incidents more frequently, and the error budget model's effectiveness depends on the deployment model producing incidents at a rate the budget model's tracking and policy can respond to before the budget is exhausted in the first week of the month. SLA breach detection: the monitoring system tracks each Enterprise Plus customer's service availability separately from the aggregate tier-1 availability, using the customer's contractual SLA definition and measurement model. When an Enterprise Plus customer's availability falls below their contractual SLA threshold for the month, the monitoring system generates an automatic alert to the VP of Engineering, the customer success lead, and the legal team. The alert is generated before the customer's legal team generates the breach notification, so that the company's response can be proactive rather than reactive. The SLA breach detection model is distinct from the internal SLO tracking model: the internal model measures aggregate tier-1 availability against the internal target; the breach detection model measures each customer's availability against their specific contractual definition.

Section 5: Reliability target review and evolution cadence. The review cadence defines when and how the reliability model is updated. Three components. Quarterly target review: the reliability targets for all tier-1 services are reviewed quarterly, using the trailing quarter's incident history, error budget consumption data, and customer feedback. The review produces one of three outcomes for each target: retained unchanged (the target is well-calibrated to current system characteristics and customer requirements), tightened (the system has demonstrated the capability to meet a more demanding target and tightening the target is appropriate), or relaxed with architectural investment (the target is not achievable with current system architecture, and the team commits to architectural work that will make it achievable within the next two quarters). The quarterly review includes a comparison of the internal SLO targets against the contractual SLA commitments for all Enterprise Plus customers, using the alignment model from section 3. SLO-SLA review is a fixed agenda item in the quarterly target review, not a separate process, because misalignment accumulates incrementally and is most efficiently caught at a point where the full picture is visible. Architecture change review: when the product's architecture changes in ways that affect reliability — the introduction of a new third-party dependency, a database migration, a service decomposition or consolidation — the reliability lead reviews the change's potential impact on the tier-1 SLOs before the change is deployed to production. The review is not a formal sign-off process; it is a fifteen-minute conversation between the engineer making the change and the reliability lead that asks three questions: does this change add a new failure mode that the current SLO measurement model would miss, does this change affect the blast radius of an existing failure mode, and does this change require a new SLA exception category to be added to the measurement model documentation. Connect this to the engineering code review velocity decision record: the architecture change review for reliability impact is the reliability equivalent of the tier-3 code review for change risk — both are processes that identify changes whose consequences extend beyond the immediate diff and require a broader review before the change is merged. Customer feedback integration: when a customer reports a reliability concern — in a support ticket, in a customer success call, or in a formal SLA breach notification — the reliability lead reviews whether the concern reflects a failure mode that the current SLO measurement model covers. Customer-reported concerns that are not reflected in internal reliability metrics are a signal that the measurement model is incomplete: the customer is experiencing something the internal model is not measuring. Each customer-reported concern that is not covered by the current SLO generates a measurement model review item in the quarterly target review — a systematic process for expanding the measurement scope as the team learns what failure modes customers actually experience, rather than the ad-hoc process of updating the SLA contract language after a breach dispute as in the second failure story.

FAQ

Further reading

• Engineering on-call model decision record — the on-call model and the reliability target model are coupled at the severity classification step: the on-call engineer's first decision after detecting an anomaly is a threshold comparison against the reliability target, and an on-call model that rotates engineers without ensuring they all have the same calibration of which threshold they are comparing against produces the first failure story's 15-minute classification debate during every incident where the visible severity is ambiguous.
• Engineering code review velocity decision record — both the severity classification model and the review risk-tier model share the same structural design requirement: tier definitions must be anchored to observable, measurable properties that the person making the classification can evaluate quickly at the moment of the decision, without needing to build a full context picture before assigning a tier; the design failure mode in both cases is subjective criteria that require judgment in a time-pressured moment rather than threshold comparison against a pre-defined measure.
• Engineering deployment frequency decision record — the deployment model and the reliability model are coupled at the change failure rate: a deployment model that ships frequent changes increases the probability of reliability incidents, and a reliability model that does not account for the change rate in its SLA calibration will produce SLA commitments that were achievable under the prior deployment cadence and are not achievable after a deployment frequency increase without a corresponding reliability investment.
• Engineering metrics decision record — the reliability metric set and the operational metric set must both be anchored at the customer experience layer to produce consistent severity classifications across the full range of failure modes; a metric set anchored at the infrastructure layer will produce correct classifications for infrastructure failures and incorrect classifications for the second failure story's class of failures, where infrastructure is healthy and customer operations are failing.
• Engineering incident retrospective decision record — the incident retrospective process should include a fixed step that reviews the incident's impact against not only the internal SLO but the contractual SLA commitments for affected customer tiers, so that the third failure story's SLA-SLO alignment gap is discoverable from the retrospective process rather than from the customer's legal team's breach notification three weeks after the quarter close.
• Open-source extractor — the reasoning behind service reliability targets decisions — why the SLO is defined in terms of customer-operation availability rather than infrastructure health, why the SLA buffer is calibrated to the team's historical miss rate rather than set at zero, why enterprise customer impact is an independent severity criterion rather than a threshold on the aggregate error rate — is reasoning conducted in AI chat sessions that does not survive into the PagerDuty alert thresholds or the SLA contract language; running those sessions through the extractor produces the decision record that allows the next engineering leader to inherit the reasoning rather than inheriting only the configuration and discovering its rationale by asking the VP of Engineering who negotiated the first enterprise contract.