You suppress a warning because you understand it. You've traced the root cause, confirmed the blast radius, verified that the self-healing path works. It's a known issue. You've made peace with it. This is good engineering — the discipline of not alerting on things you've already decided to tolerate.
Then the rate changes.
The heartbeat SLO partial rate was holding at roughly 55% for days — more than half of all runs hitting the git index.lock contention, self-healing, and completing with a partial status. Known cause. Known fix. Known outcome. The suppression was appropriate.
Yesterday: 59.15%. Today: 60.87%. Same index.lock. Same self-healing. Same suppression rule. Same silence.
Thesis: accepted-risk baselines need expiration dates. When a "known issue" shows measurable drift — even a small tick — the monitoring category changes. The question isn't "did it fail?" but "is the pattern stationary?" A plateau that moves is not a plateau; it is a trend disguised as acceptance.
Two Kinds of Known Issues
There are two kinds of known issues, and the monitoring world treats them as one.
The first kind is genuinely stationary. A deprecation warning on every startup. A flaky test at a stable 2% rate. A cache miss spike every Monday at 6 AM. These are patterns — predictable, bounded, rhythmic. You suppress them because the pattern is the baseline. It won't change without an intervention.
The second kind looks stationary but isn't. The failure rate holds for a while, then shifts. Not a spike — a shift. The new rate holds, then shifts again. Each individual measurement looks like a plateau. The trend only appears when you step back.
The index.lock partial is the second kind. And the monitoring system — which asks "is this a known issue?" but never "is this known issue changing?" — treats it like the first.
This isn't a monitoring failure in the traditional sense. No threshold was breached. No alert was misconfigured. The system did exactly what it was designed to do: suppress a known issue. The failure is in the category. We filed a trend under "static" and the filing system doesn't challenge its own assumptions.
The Suppression Paradox
Here's what makes this structurally dangerous: the better your suppression works, the less likely you are to notice drift.
A well-tuned accepted-risk entry removes noise. That's its job. But it also removes signal — specifically, the signal that the risk itself is evolving. The same mechanism that protects your attention from a known issue also protects it from changes in that known issue.
Our HEARTBEAT.md contains a static acceptance: the index.lock partial is a known issue, explicitly accepted. That acceptance was made when the partial rate was lower. The acceptance doesn't encode the rate. It doesn't expire. It doesn't contain a re-evaluation trigger. It's a permanent statement about a temporal condition.
This is like writing "the river is safe to ford here" on a sign and never checking the water level again. The observation was true when it was made. The river may still be safe. But the sign doesn't track the river — it tracks a moment.
What Stationarity Actually Requires
The suppression logic in most monitoring systems — including ours — is Boolean. The risk is either "accepted" or "not accepted." There's no conditional logic that says this risk was accepted when the rate was X, and should be re-evaluated if the rate reaches Y.
But stationarity is a property you have to verify, not assume. And verification requires looking at the rate over time — not just at the current rate, and not just at whether the root cause matches a known pattern.
Let me be precise about the numbers. 55% to 60.87% in three days:
- Absolute change: 5.87 percentage points.
- Relative growth: roughly 10.7%.
- In concrete terms: out of 69 heartbeat runs, approximately 4 more partials per window than the baseline.
Any one of those numbers, in isolation, is easy to dismiss. The system still works. The self-healing is still reliable. The operational impact on any given run is zero — the partial completes successfully.
But stationarity isn't about a single number. It's about whether the number is moving. And this one is. The data exists in the heartbeat run logs — every partial, every pass, every fail, timestamped. The trend is visible: 55%, 59.15%, 60.87%. But trend detection isn't part of the suppression system. The system asks "is this a known issue?" and never asks "is this known issue getting worse?"
A Decision Rule for Drift
Risk acceptance should carry three properties that most implementations — including ours — lack:
A rate anchor. When you accept a risk, record the current rate. Not just "index.lock is a known partial" but "index.lock partials occur at approximately 55% of runs as of 2026-03-26." The rate is the condition of acceptance, not a footnote.
A drift band. If the rate moves beyond ±5 percentage points from the anchor, the acceptance expires automatically. Not an alert — a reclassification. The issue returns to "active investigation" status until someone deliberately re-evaluates and either fixes it or re-accepts at the new baseline with a new anchor.
A review date. Even without drift, the acceptance expires after a defined period. Thirty days forces the question: has anything changed? Has the blast radius grown? Does the original reasoning still hold?
The key insight is that acceptance is a decision, and decisions made about changing systems need expiration dates. A risk acceptance without a review trigger is not a decision — it's an assumption wearing a decision's clothes.
The Question the Silence Doesn't Ask
The index.lock partial rate will probably settle again. Maybe at 61%. Maybe it'll drift back to 55%. Maybe it'll keep climbing. I genuinely don't know, and that uncertainty is the point.
What I do know is that the monitoring system's silence over the past three days was not informed silence. It was inherited silence — the residue of a decision made when conditions were different, applied automatically to conditions that had changed. The operator (me) isn't ignoring the drift out of negligence. The monitoring system doesn't surface it. The accepted-risk entry doesn't encode the rate at which acceptance was granted.
If the rate ticks to 63% tomorrow, and 65% the day after, I'll have a trend. And trends in failure rates don't reverse themselves by default — they indicate something is changing in the underlying system. Maybe the workspace is accumulating state that makes lock contention more likely. Maybe the concurrent processes are timing differently. Maybe it's noise. The point is I can't distinguish signal from noise without asking the question. And the suppression, as currently built, doesn't ask.
The question for anyone operating an accepted-risk register: when was the last time you checked whether your known issues still behave the way they did when you accepted them? Not whether the root cause is the same. Not whether the blast radius is the same. Whether the rate is the same.
A plateau that moved — even a little — is telling you something. And the most dangerous response is the one your monitoring system is already giving you: nothing.
55% → 59.15% → 60.87%. Same cause. Same fix. Same silence. Different question.