Any tool that warns you about slipping work has a number in it somewhere. How many days of silence before a task counts as stale. How far behind an iteration has to fall before it goes amber. How close a due date has to be before anyone hears about it. That number is a judgement call, and it is the least discussed part of the entire category, because it is where a warning system either earns its place or quietly becomes furniture.
Get it wrong in one direction and the tool shouts at everything. People stop reading, build a filter to mute it, and start tracking the real risks in a side channel. Get it wrong in the other and the tool sits there approving of everything, and you are back to relying on someone noticing in time. Both are failures. Only one of them ever generates a complaint, and that asymmetry is what actually kills alerting systems.
The two ways to be wrong
A threshold that is too tight produces alerts on work that was never in trouble. A task that has not moved in two days because the person doing it is heads-down. An iteration slightly behind on day three of ten. A date that shifted for a good reason everybody already knows. Individually each of these is a small wrong. Collectively they teach the team a rule: the flags do not mean anything. Once that rule is learned it is nearly impossible to unlearn, and it applies to the real ones too.
The reaction is rarely a considered one. Nobody sits down and decides to distrust the tool. They just start clearing notifications without reading them, filtering the digest to a folder, glancing at the red count and thinking yeah, it always says that. The system is still running. It has simply been routed around, and from the tool’s own point of view nothing is wrong at all: alerts fire, alerts get marked as seen.
A threshold that is too loose fails in the opposite way and looks like nothing at all. The tool is calm. The dashboards are green. Everyone assumes the quiet means health, and the first sign of trouble arrives the way it always did before you had the tool, through a client email or a missed date, which is to say you are back to being the system yourself, only now with a subscription.
Only one failure is loud
Here is the mechanism that matters, and it is why this is not simply a matter of picking a better number.
When a system over-alerts, people complain. Loudly, immediately, and with examples. This flagged a task I finished yesterday. Why did I get eleven of these on Friday? The feedback is specific, it is attributable, and it comes with an obvious fix: relax the threshold.
When a system under-alerts, nobody complains at all. There is no ticket titled “the warning I needed never arrived”, because the whole point of a miss is that nothing showed up to notice. The project went sideways and it got blamed on the client, the scope, the estimate, the developer who went quiet. The absent alert is never in the list of suspects, because it left no trace.
So the only feedback a threshold ever receives pushes one way. Every round of tuning is a response to noise, and every response to noise is a loosening. Do that for a year and you end up with a system that has been carefully, iteratively, sensibly adjusted into saying almost nothing. It still runs. It is still on the invoice. It has been optimised for the absence of complaints rather than the presence of warnings, and those are not the same target.
If your alerting has been stable and quiet for months, that is not evidence it is calibrated. It is the expected end state of the feedback loop regardless of whether it works.
A single number cannot be right
The instinct at this point is to hunt for a better default. There isn’t one, because the question how long is too long? has no answer independent of the work being measured.
Two days of no movement on a production hotfix is alarming. Two weeks of no movement on a discovery task with a date six weeks out is completely normal. A one-day slip on a task that sits on the critical path of a client delivery matters more than a five-day slip on something with slack on either side. Any single global threshold has to be wrong for most of these, and the way it is wrong is not random: it will be too tight for the slow, exploratory work and too loose for the urgent, dependent work. Which is precisely backwards, because it means the noise comes from the work that matters least and the silence covers the work that matters most.
This is why the fix is not a dial. A threshold worth trusting has to be relative to the thing it is measuring: to the size of the task, the distance to its date, whether anything downstream is waiting on it, how work of this kind normally behaves. A tool that asks you to pick “alert after N days” is handing you a problem it was in a far better position to answer than you are, and the setting exists mostly so that the miscalibration becomes your fault rather than its own.
Two numbers nobody tracks
If you want to know whether your warnings are calibrated, there are exactly two things worth counting, and almost no team counts either.
Misses. Of the things that went wrong last quarter, how many arrived with no warning from the tool? Not “was it in there somewhere if you had gone looking”, but did anything actively tell you. This is the number that never generates its own feedback, so it has to be gathered deliberately, after the fact, or it does not exist.
Ignored alerts. Of the warnings that fired, how many led to somebody doing something? Not reading, not dismissing. Acting. A warning that has never once changed a decision is not a warning, whatever the interface calls it.
Run both for a quarter and the diagnosis is immediate. High misses, low noise: too loose, and it has probably been drifting that way for a while. Lots of alerts, almost no action: too tight, and the team has already stopped reading whether they have told you or not. Both numbers low is the only state worth having, and it is rarer than the dashboards suggest.
Neither number is hard to collect. They are just nobody’s job, which is why a system can be badly calibrated for years without anyone being able to say so with evidence.
SRP sets its thresholds against the work rather than asking you to pick a global sensitivity, because the right answer for a two-day hotfix and a six-week discovery task was never going to be the same number.