The alerting threshold decision record: why the alert sensitivity you configured determines your on-call storm surface and your signal-to-noise ratio failure mode

A 32-person SaaS company built a document collaboration platform that launched with a straightforward alerting setup: error rate above 5% for any service pages primary on-call, queue depth above 500 pages secondary on-call, and individual endpoint latency above two seconds pages the service owner. The thresholds were calibrated in the first week of production. The system was handling approximately 200 requests per minute at launch, the error rate was averaging 0.3%, and the queue depth was staying under 30. The absolute values — 5% error rate, queue depth 500, two-second latency — seemed conservative. They paged twice in the first three months, both genuine issues that the on-call engineer investigated and resolved. The alerting configuration was marked as working and not revisited.

Eighteen months later, the platform was serving 80,000 requests per minute across 31 microservices. The alerting configuration had grown as the platform had grown: each new service had new alert rules added at launch, calibrated against its own traffic at the time it launched, using the same absolute-value model the team had established at the beginning. The aggregate alert inventory was 94 individual rules across the 31 services, each with its own threshold, each calibrated independently at a different traffic baseline.

At 2:17am on a Wednesday, the primary database cluster initiated a planned failover — a maintenance operation that had been scheduled and announced two weeks earlier. The failover itself completed in forty-one seconds. During those forty-one seconds, every service that depended on the database experienced elevated error rates, increased response latency, and growing queue depths simultaneously, as in-flight requests failed and retrying clients amplified the load on the recovering cluster.

The on-call engineer's phone began paging at 2:17:03am. By 2:17:07am — four seconds later — she had received nineteen pages. By 2:21:00am, the phone had delivered 847 pages. The pages were not duplicates: each one corresponded to a different alert rule that had crossed its threshold during the failover window. The queue depth alerts fired because queues briefly accumulated during the recovery. The latency alerts fired because responses slowed during the failover. The error rate alerts fired across eleven services because in-flight requests against a recovering database returned errors. Every alert rule was firing correctly. The alerting system was functioning as designed.

The on-call engineer acknowledged the first page, read the alert description — "auth-service: error_rate > 5% (current: 34%)" — and understood immediately that a database failover was in progress. She opened the operations dashboard, confirmed the failover status, and waited for the cluster to stabilize. The recovery completed at 2:18:26am — eighty-three seconds after the failover began. She documented the incident: planned failover, monitoring confirmed recovery, no customer impact, no action required. The diagnosis and documentation took twenty-three seconds.

The remaining 828 pages had already been delivered. She spent eleven minutes clearing the PagerDuty alert queue — acknowledging each of the 847 fired alerts, most of which had already auto-resolved by the time she reached them, because the system had recovered before she could investigate them. Eleven minutes of cognitive overhead for a twenty-three-second diagnosis. The company's on-call response time SLA required acknowledgement within five minutes for P1 incidents. Because the alert storm had flooded the queue before she could triage, three genuine medium-severity alerts — unrelated to the database failover — had been buried in the noise and were not acknowledged within the SLA window.

The founding session that had defined the alerting model — error rate above N%, queue depth above M, latency above Xms — had not specified whether alert rules should be expressed as absolute values or as ratios. It had not specified a recalibration cadence. It had not specified how multiple alert rules firing simultaneously from a single root cause should be grouped or suppressed. Each of those omissions had been reasonable at launch: at 200 requests per minute with 8 services and 12 alert rules, an alert storm was theoretically possible but not operationally plausible. At 80,000 requests per minute with 31 services and 94 rules, the same absolute thresholds had become a storm generator embedded in the system's normal operating envelope.

A 28-person product SaaS ran a background job processing system that handled webhook deliveries, email sends, and report generation. The jobs were queued in Redis, processed by eight worker instances, and monitored by a set of alert rules the team had built up over two years: queue depth above 200, job failure rate above 8%, worker CPU above 90% for five minutes, dead-letter queue growing by more than ten items per hour.

The dead-letter queue alert had been added after an incident in month eight where a bug in the email composition library had caused a class of jobs to fail silently, accumulate in the dead-letter queue, and go undetected for six hours. The threshold — growing by more than ten items per hour — had been selected as sensitive enough to catch the next such accumulation early. In the first two weeks after the alert was enabled, it fired three times: once for a deployment that caused a brief spike in job failures, once for a batch of malformed webhook payloads from a customer API integration, and once for an unexpected format change in an external report data source. All three fires were legitimate signals. The on-call engineers investigated, identified the causes, and filed issues for follow-up.

Over the next four months, the dead-letter queue alert began firing more frequently. The causes were varied: a new customer with an unusual webhook retry pattern, a Redis memory pressure event that caused brief processing delays, a third-party API rate limit that caused temporary job failures before the retry logic caught up. Most of these events resolved within fifteen to thirty minutes without any action from the on-call engineer. The alert fired, the engineer acknowledged it, checked the dead-letter queue depth and growth rate, confirmed the trend was decelerating, and closed the alert. No runbook action. No remediation. The alert resolved itself.

By month fourteen, the dead-letter queue alert was firing an average of eleven times per week. The engineers on the on-call rotation had seen this pattern hundreds of times. The alert meant: check the dead-letter queue depth, confirm it is not growing exponentially, check if there is a visible cause in the logs, close if the trend is decelerating. The check took less than sixty seconds. The acknowledge-and-close became reflexive.

At 2:14am on a Saturday, the dead-letter queue alert fired again. The on-call engineer — a developer named Tom who had been on the rotation for four months and had handled this alert eighteen times — acknowledged it in eight seconds. He did not open the monitoring dashboard. He closed the alert and returned to sleep. The dead-letter queue was not experiencing its normal transient accumulation pattern. A database migration that had been deployed at 11pm had introduced a schema change that made the job deserialization logic fail for all new jobs — not a subset, not a batch, every job queued after 11pm. The dead-letter queue was growing at 340 items per hour, not the transient 15–25 items per hour that signaled a normal event. The exponential growth curve was visible in the alert payload, in the same text field Tom had read fifty-one characters of before closing the alert in eight seconds.

The database migration had silently broken job processing for three hours and fourteen minutes before a customer submitted a support ticket at 5:28am reporting that their scheduled report — the one that should have been in their inbox at 3am — had not arrived. The engineering team identified the schema mismatch at 5:41am, deployed a fix by 6:17am, and spent the following six hours reprocessing the failed job queue and handling customer inquiries about missing deliveries. Forty-seven customer accounts were affected. Eleven required individual outreach.

The founding session for the alerting system had not documented an actionability standard — the requirement that every page-worthy alert have a specific runbook step the on-call engineer can execute. It had not documented a review cadence for evaluating whether alert thresholds were still producing actionable signals or had drifted into noise. It had not documented the ratio of investigated alerts to closed-without-investigation alerts as a metric to track. The threshold that had been calibrated as sensitive enough to catch a real issue in month eight had accumulated fourteen months of non-actionable fires against the same threshold, and the training effect of those fourteen months — that this alert closes itself if you wait long enough — had overridden the judgment that should have applied to the Saturday 2am case where the pattern was unambiguously different.

A 41-person B2B SaaS company built an analytics API that served data queries for enterprise customers. The API's alerting configuration included a p95 latency threshold: if the 95th percentile response time across all API requests exceeded 800 milliseconds over a five-minute window, the on-call engineer was paged. The 800ms threshold had been set based on the API's behavior at launch, when p95 latency was averaging 180ms and the 800ms value represented a four-sigma deviation from the mean.

The alert worked well for eighteen months. It fired twice for genuine latency events — once during a database index rebuild, once during a memory pressure event — and resolved cleanly both times. The p95 threshold was producing signal without noise. The alerting configuration was considered stable.

In month twenty, the company signed an enterprise contract with a financial services firm. The firm's usage pattern was different from the company's existing customers: they ran large, complex analytical queries against multi-year historical datasets, their engineering team made API calls from infrastructure running in a European data center, and their queries were computationally intensive enough that response times were consistently 400–600ms — high relative to the median customer but within the p95 because most other customers made lighter queries from US-based infrastructure.

On a Tuesday afternoon, a CDN edge node serving traffic from the European region began experiencing elevated network latency between its origin connection and the company's API infrastructure. The root cause was a BGP routing change at a peering exchange that added approximately 180ms of round-trip time to requests transiting that exchange. The CDN provider's monitoring systems detected the event, classified it as within their acceptable SLA envelope, and began routing around the affected path — a process that took forty-three minutes to complete.

During those forty-three minutes, API calls from the enterprise customer's European infrastructure experienced response times of 600–900ms, occasionally spiking to 1,400ms during peak query periods. These response times crossed the company's internal threshold of what their engineering team considered degraded performance. But the system-wide p95 latency metric — the one driving the alert — was unaffected. The European customer's traffic represented 4% of total API call volume. Their elevated response times did not move the p95 in a way that crossed the 800ms threshold. The metric was accurate: 95% of the company's users were experiencing normal API performance. The alert correctly did not fire.

The enterprise customer's engineering team noticed the degradation at the fourteen-minute mark when their dashboard began showing query timeouts. They escalated internally, confirmed the problem was isolated to their environment, and filed a support ticket at 2:51pm — forty minutes into the incident. The support team logged the ticket as a P2 and assigned it to the on-call engineer. The on-call engineer identified the CDN routing issue at 3:04pm, confirmed with the CDN provider that the event was being remediated, and closed the ticket at 3:47pm after latency returned to baseline.

The enterprise contract included an API availability and latency SLA: 99.9% of requests under 500ms, measured per customer account, per calendar month. The incident had produced seventeen minutes of responses above 500ms for that customer's account — not enough to breach the monthly aggregate, but enough to appear in the SLA report that the customer's vendor management team reviewed. The incident generated three follow-up meetings between the company's CTO and the enterprise customer's VP of Engineering about the monitoring gap: why had no alert fired for forty minutes of customer-impacting latency? The honest answer was that the company monitored aggregate system performance, and the customer's SLA was a per-account commitment that the company's alerting architecture had never been configured to track.

The founding session had documented the latency alert threshold without specifying whether it applied to aggregate system metrics or to per-customer or per-segment metrics. It had not specified how enterprise SLA commitments would be translated into monitoring thresholds. It had not specified the review trigger that should fire when the customer base added a segment — geographic region, usage pattern, computational intensity — that was no longer well-represented by the existing aggregate metric. The p95 threshold that was an accurate proxy for customer experience at launch remained unchanged while the customer population evolved to include a segment that the p95 systematically masked.

Structural properties set by the alerting threshold decision

Three structural properties are determined when a team decides how to configure alert thresholds. None appear explicitly in the session that sets up PagerDuty, configures Alertmanager, or writes the first Terraform alert module — they are operational characteristics that emerge from the threshold configuration's assumptions about scale invariance, signal actionability, and the relationship between aggregate metrics and individual customer commitments.

Property 1: The alert storm and the threshold recalibration surface. Alert thresholds defined as absolute values — error count above N, queue depth above M, request duration above Xms — are calibrated against the system's behavior at the moment they are configured. They are not calibrated against the system's behavior at any future moment. As traffic grows, absolute error counts that were rare become routine; as services multiply, alert rules that were isolated become correlated through shared dependencies. The alert storm surface grows whenever the product of (traffic scale) × (number of alert rules) × (shared dependency coupling) increases while the alert threshold values remain constant. The surface closes by two mechanisms: recalibration triggers (documented conditions under which threshold values are reviewed and updated — every quarter, every significant traffic increase, after every operational incident that revealed a miscalibrated threshold) and scale-invariant alert definitions (expressing thresholds as ratios and percentiles rather than absolute values, so the threshold adapts automatically as scale changes). The on-call rotation design decision record specifies who handles the pages that the alerting configuration generates; this document specifies how the configuration is calibrated to generate the right pages — the upstream decision that determines whether the rotation design is operating within its design envelope or being overwhelmed by noise the rotation was not designed to absorb. A recalibration cadence that is not documented in the alerting ADR will not happen: the sprint backlog does not spontaneously produce "recalibrate all alert thresholds" tasks, and the team that configured the alerts three years ago has mostly turned over. The recalibration trigger must be explicit, owned, and attached to observable events (traffic milestones, service count milestones, quarterly reviews) to survive the team turnover that happens between the founding configuration and the alert storm that reveals the calibration is wrong.

Property 2: The alert fatigue and the actionability guarantee surface. An alert that fires on a condition the on-call engineer cannot act on is not neutral — it is actively harmful. Each non-actionable page is a conditioning event that moves the on-call team's response behavior slightly toward reflexive acknowledgement and slightly away from investigative triage. The conditioning effect is invisible in individual incident records (the page was acknowledged, the engineer checked, nothing to do, closed) and visible only in the aggregate signal: the ratio of pages closed with documented remediation steps to pages closed without any. Operationally healthy alerting configurations show this ratio above 80%; configurations with significant non-actionable alert accumulation show it below 50%. The actionability guarantee is the structural requirement that every page-worthy alert has a specific runbook step the on-call engineer can execute within five minutes of waking. Alerts that cannot satisfy this requirement are not page-worthy. They belong in one of two lower-severity categories: ticket-worthy (automatically creates a support ticket for investigation the next business day, no page) or dashboard-visible (appears in the monitoring dashboard as a signal for context, no notification). Documenting this classification in the alerting ADR does two things: it creates an ongoing review gate for new alert rules (can you write the runbook step before adding the rule?) and it creates an audit mechanism for existing rules (which rules have not produced a documented remediation step in the last quarter?). The observability strategy decision record documents the metrics, traces, and logs that produce the signals the alert rules are based on; this document specifies which of those signals warrant waking an engineer and which warrant a ticket or a dashboard entry — the actionability classification that converts observability data into on-call obligations.

Property 3: The alerting blind spot and the tail customer surface. Aggregate metrics — p95 latency, system-wide error rate, overall throughput — are computed across all customers, all regions, all request paths, and all customer tiers simultaneously. The aggregate is the right metric for understanding the system's average health. It is not the right metric for detecting localized degradation that affects a specific customer segment while leaving the aggregate unaffected. The tail customer surface is the set of customers whose experience is masked by the aggregate: the enterprise customer in a region with higher baseline latency, the customer with a computationally intensive access pattern whose p95 response time is worse than the system-wide p95, the customer tier whose contractual SLA is tighter than the metric threshold used to monitor it. This surface is structurally invisible in a monitoring configuration built around aggregate metrics only. It becomes visible only when a customer reports the problem — which is the slowest possible detection mechanism and the most damaging to customer trust. The alerting ADR closes this surface by requiring that every customer-segment-specific SLA commitment be translated into a corresponding monitoring threshold: if the enterprise contract guarantees p99.9 latency under 500ms per customer account, there must be an alert that fires on per-account p99.9 latency. This connection between contract terms and monitoring thresholds is not automatically maintained — it requires the alerting ADR to specify the trigger for updating alert rules when new customer segments with distinct SLA commitments are added, and it requires the sales and engineering teams to share the SLA terms at contract signing rather than at the first SLA breach. The SLO and error budget decision record specifies the service level objectives that define the team's reliability commitments at the system level; the alerting threshold ADR specifies how those commitments are decomposed into per-customer, per-segment, and per-endpoint monitoring thresholds that can detect a breach before a customer reports it.

What the founding session records and what it omits

The founding alerting session — typically part of a broader "how do we know when something is broken" infrastructure conversation in the first sprint after launch — records the tool choice (PagerDuty configured, Alertmanager installed, Datadog monitors enabled) and the initial threshold values for the obvious metrics (error rate, latency, availability). What it does not record is the operational model that the threshold values require to remain accurate over time: the recalibration trigger, the actionability standard, the relationship between aggregate metrics and customer-specific SLA commitments.

These omissions are structurally the same as every other founding-session decision in this series: the failure modes are theoretical at founding, when the system is simple, the team is small, the customer base is homogeneous, and the person who configured the thresholds is the same person who answers the pages. A recalibration trigger is unnecessary when you are one engineer and you know every threshold you set last month. An actionability standard is unnecessary when there are twelve alert rules and the team reviews all of them in a monthly retrospective. A per-customer monitoring requirement is unnecessary when all customers have identical usage patterns and no contractual SLA differences.

The failure modes develop on different timelines. The alert storm develops as a function of traffic and service count growth — it can arrive in eighteen months at a fast-growing B2B SaaS, or in four years at a slower-growing company, but it arrives reliably when absolute-value thresholds are never recalibrated. Alert fatigue develops as a function of the non-actionable alert accumulation rate — it builds slowly, one reflex at a time, and is undetectable in any individual incident because each acknowledged-and-closed alert looks identical whether the close was a valid "nothing to do" or a conditioned "I don't bother checking anymore." The tail customer blind spot develops as a function of the customer base's diversification from the homogeneous baseline at launch — it is invisible until the right customer in the right situation experiences the right localized failure while the aggregate metrics remain green.

The alerting threshold ADR closes this gap not by predicting which failure mode will arrive first, but by documenting the operational model that prevents all three: the recalibration trigger that ensures thresholds stay calibrated to current scale, the actionability standard that prevents non-actionable alerts from accumulating and training the on-call team to stop investigating, and the SLA-to-threshold translation requirement that ensures customer-specific reliability commitments are reflected in the monitoring configuration that would detect a breach. These are not complex requirements, but they are not requirements that emerge naturally from the alert configuration itself. They must be stated explicitly in the ADR, owned by a named individual or team, and connected to observable triggers that cause them to be reviewed. Without that explicit documentation, the recalibration review does not happen, the actionability audit does not happen, and the SLA-to-monitoring translation does not happen — not because the team is negligent, but because the sprint backlog does not surface them, the monitoring dashboard does not show them, and the incidents that would reveal them arrive too infrequently and too violently to produce systematic improvement without a documented framework for acting on them. The decisions never written down in the alerting domain are rarely the threshold values — "we alert at 5% error rate" appears in every Terraform module comment. They are the recalibration trigger that determines when the 5% threshold gets revisited, the actionability standard that determines whether an alert that has never produced a remediation step in six months should still be paging the on-call rotation, and the per-customer monitoring requirement that determines whether the enterprise contract the sales team signed last quarter produced a new monitoring obligation that engineering needs to implement. Those decisions accumulate interest as the system scales, the customer base diversifies, and the on-call rotation's reflex for non-actionable alerts grows more practiced than its judgment for the ones that matter. The new CTO onboarding problem is acute for alerting specifically: the incoming technical leader finds the Terraform alert modules and knows the threshold values, but cannot determine whether those thresholds were ever recalibrated after launch, whether there is an actionability standard for adding new alerts, or whether the enterprise SLA commitments the company has signed are reflected in monitoring thresholds that would detect a breach. The alerting threshold ADR makes those decisions explicit, auditable, and findable before a database failover generates 847 pages, before a Saturday 2am acknowledgement closes an alert that should have woken the entire team, or before an enterprise customer spends forty minutes in degraded service while every aggregate dashboard shows green. The WhyChose extractor finds the alerting discussion in your AI session history — the conversation where your founding engineer chose the tool, calibrated the first thresholds, and decided whether to alert on absolute values or ratios — and surfaces the commitments made in that session, so you can check which of the three operational model elements were documented and which were left to drift as the system and customer base grew.

The alerting threshold ADR: five sections

Section 1: Threshold definition model and scale-invariance policy. Specify whether alert thresholds are defined as absolute values or as ratios and percentiles. For each alert rule in the initial configuration, document the rationale for the threshold value and the traffic baseline at which it was calibrated. If absolute values are used, specify the recalibration trigger: the conditions under which threshold values are reviewed and updated. At minimum, include a calendar-based trigger (quarterly review, or after every order-of-magnitude traffic increase) and an event-based trigger (after any incident where an alert storm or missed alert was identified as a contributing factor). Identify the named owner of the recalibration review — the individual or team responsible for running the review when the trigger condition is met. If SLO-based alerting is used (alerting on error budget burn rate rather than absolute error counts), document the SLO that each alert rule is derived from and the burn rate threshold that corresponds to the urgency level of the page. SLO-based alerting does not require recalibration as traffic scales because it is expressed relative to the reliability commitment, not relative to the absolute traffic volume; document this property explicitly so future engineers understand why the SLO-derived rules need no maintenance while the absolute-value rules require active recalibration. The SLO and error budget decision record is the upstream dependency: alert rules derived from SLOs cannot be designed without the SLO targets being defined first.

Section 2: Actionability standard and alert classification. Specify the actionability standard: the requirement that every page-worthy alert has a documented runbook step that the on-call engineer can execute within five minutes of acknowledging the page. Document the enforcement mechanism: before a new alert rule is added to the on-call alert set, the runbook step must be written and reviewed. Specify the classification for alerts that do not meet the actionability standard: ticket-worthy (creates a ticket for next-business-day investigation, no page) and dashboard-visible (visible in the monitoring UI as a leading indicator or contextual signal, no notification). Specify the review cadence for existing alert rules: every quarter, compute the ratio of acknowledged-with-documented-remediation to acknowledged-without-remediation for each alert rule. Alert rules below 50% documented remediation are candidates for demotion to ticket-worthy or dashboard-visible status. Specify the process for demotion: who can propose it, who approves it, and how it is documented so it is not silently re-promoted in a future incident review. Also specify the suppression and deduplication model: identify which alert rules are downstream symptoms of common root causes, and document the parent/child suppression configuration (Alertmanager inhibit_rules, PagerDuty alert grouping, or equivalent) that prevents a single root-cause event from generating N simultaneous pages for N downstream symptoms. The goal is one page per incident, not one page per affected alert rule.

Section 3: SLA-to-monitoring translation requirement. Specify the process by which customer-facing SLA commitments are translated into corresponding monitoring thresholds. If a customer contract guarantees p99.9 API latency under 500ms per customer account, there must be an alert rule that monitors per-account p99.9 latency and fires before that SLA is breached. Document who is responsible for reviewing new customer contracts for SLA commitments, the timeline for translating new commitments into monitoring thresholds (before the contract is signed, or within the first deployment to the customer's environment), and the review cadence for confirming that all active enterprise SLA commitments have corresponding monitoring thresholds. Specify the metric granularity requirements: if the SLA is per-account, the metric and alert must be per-account; if the SLA specifies a geographic region, the metric must be per-region. System-wide aggregate metrics cannot satisfy per-account or per-region SLA monitoring requirements by definition — a per-account p99.9 that is four times the SLA threshold is invisible in the system-wide p95 if the account represents less than 5% of total traffic. This section is operationally important because it creates a coordination requirement between the sales team (which signs contracts) and the engineering team (which implements monitoring) that does not exist in many early-stage companies and must be explicitly established rather than assumed.

Section 4: Alert grouping, parent/child suppression, and storm prevention. Specify the alert grouping model used to prevent alert storms. Document the shared dependencies in the system that, when they fail, trigger multiple alert rules simultaneously: the database, the message broker, the CDN, the external authentication provider, the primary cache layer. For each shared dependency, identify the alert rules that are downstream symptoms of its failure, and document the suppression configuration: when the database-connectivity alert fires, the alerts for elevated API error rates across all services, queue processing failures, and report generation failures should be suppressed — they provide no additional diagnostic information and multiply the on-call engineer's notification load without multiplying their ability to respond. Also specify the alert evaluation window: alert rules evaluated over short windows (thirty seconds or less) will fire multiple times during a brief fault; alert rules evaluated over five-minute windows will fire once and auto-resolve if the fault clears. For each alert rule, document the evaluation window and the rationale for its length. Short windows are appropriate for synchronous request handling failures where rapid detection is critical; longer windows are appropriate for resource accumulation signals (queue depth, disk usage, connection pool saturation) where trend direction matters more than point-in-time value. Document the flap suppression configuration: the number of consecutive evaluation windows that must show the condition before paging, to prevent repeated firing when a metric oscillates around a threshold. Most alerting platforms implement this as a "for" clause (alert fires only if condition is true for N consecutive minutes); document the minimum threshold — typically five minutes for operational alerts, shorter for hard customer-facing availability signals.

Section 5: Alert review cadence and threshold drift detection. Specify the operational review process that prevents alerting thresholds from drifting out of calibration. Document the quarterly alert review: the metrics reviewed (acknowledged-with-remediation ratio per rule, alert frequency per rule, time-to-acknowledge per severity, ratio of acknowledged-to-auto-resolved alerts), the decision criteria for recalibrating a threshold (frequency too high compared to the remediation ratio, suggesting non-actionable fires; frequency too low combined with missed incidents, suggesting the threshold is too conservative), and the format for documenting the review outcome. Specify the incident-triggered review: after any incident where an alert storm contributed to delayed diagnosis, or where an alert did not fire for a customer-impacting event, the alerting configuration for that incident's affected components is reviewed in the postmortem and updated before the postmortem is closed. The incident response playbook decision record specifies the postmortem process; this section specifies that the alerting configuration review is a required step in every postmortem for incidents where alerting behavior (storm, fatigue, or blind spot) was a contributing factor — and that the output of that review step is a specific change to the alerting threshold ADR, not a ticket for future consideration. Specify who owns the alerting configuration as a system: the individual or team responsible for the quarterly review, for the incident-triggered review, for approving new alert rules against the actionability standard, and for maintaining the SLA-to-monitoring translation log. Alerting configurations that are owned by everyone are maintained by no one; the ADR must name the owner explicitly so that the recalibration reviews, actionability audits, and SLA translation processes have a single accountable party who cannot assume someone else is handling it.

FAQ