# What a baseline cannot tell you > A baseline records what happened during the period it was taken and silently promotes that period's conditions to the status of normal. It answers whether something changed, which is worth having — but it cannot tell you whether the thing it recorded was ever right, and the difference between those two questions is where confident wrong answers come from. Source: https://ronutz.com/en/practice/what-a-baseline-cannot-tell-you Stance: practised Updated: 2026-08-09 --- ## The comparison that ends an investigation early The baseline says memory sat at 41% and the retransmission rate was 0.3%. Today it is 43% and 0.3%. Nothing has moved. The room relaxes and the investigation turns elsewhere. That is often correct, and it is the reason [baselines](https://ronutz.com/en/practice/baselines-knowing-what-normal-looks-like) are worth the trouble. It is also the single most efficient way to rule out the actual cause, because a matching baseline feels like evidence of health when it is only evidence of **sameness**. > **A baseline answers "has this changed?" It does not answer "is this right?"** Those look like the same question during an incident and they are not, and the second one is usually the one on the table. ## Everything it recorded, it also endorsed The capture is silent about its own conditions. Whatever was true on the day becomes the reference, including the parts that were already wrong. A device already misconfigured is recorded as normal. A link already running hotter than it should is recorded as normal. A memory leak already three weeks into its climb is recorded at whatever value it had reached, and every future comparison measures against a number that was itself a symptom. **This is not a flaw in the practice; it is what a snapshot is.** But it means a baseline can only ever tell you how far you have moved from a point — never whether the point was a good place to stand. ## Four things it cannot see, however carefully it was taken **What was already wrong.** As above, and worth stating separately because it is the failure that costs most: the baseline becomes the argument for *not* looking somewhere. **What the conditions were.** A capture taken in the quiet week of January and one taken at month-end close describe different systems. Neither is wrong; comparing them is. Without the conditions recorded, the comparison silently spans two different questions. **Anything below its resolution.** A quarterly snapshot cannot speak about a Tuesday. If the symptom is a two-second stall, a set of counters read once a quarter has nothing to say about it — and its silence will be read as absence, which is the [when the instruments agree](https://ronutz.com/en/practice/when-the-instruments-agree) error arriving from the past instead of from a dashboard. **Whether the thing it measured is still the thing that matters.** The estate changed. A capacity number for a component that now carries a tenth of what it did is still accurate and no longer relevant, and it will keep looking reassuring indefinitely. ## The specific trap: a matching baseline as proof of innocence The dangerous sentence is *"we checked against the baseline and it is the same, so it is not that."* Sameness rules out **change**. It does not rule out the component. If the fault is a design limit rather than a drift — a table that was always going to fill at this transaction rate, a timeout that was always slightly too short for this path, a licence ceiling reached by growth that is entirely normal — then **the baseline will match perfectly right up to the moment the system stops working**, and the match will have been used as a reason to look elsewhere. Every one of those faults is invisible to a comparison and obvious to a first-principles reading of the design. That is why this article sits beside [reading a design you did not write](https://ronutz.com/en/practice/reading-a-design-you-did-not-write) rather than replacing it. ## What to do with a baseline that matches Not discard it. Downgrade what it is being asked to prove. **Say what it actually established**, out loud, in the words that survive: *"nothing has drifted since March"* rather than *"the platform is healthy."* The first is what you have. The second is what the room will hear if nobody says the first. **Then ask the question the comparison could not**: is this value correct for the load this system now carries? That is a design question, answered from the specification and the arithmetic rather than from history, and it is the one a matching baseline actively discourages anybody from asking. ## The four questions Before letting a baseline rule anything out: 1. **When was it taken, and what was happening that week?** If the conditions are not recorded, the comparison is weaker than it looks. 2. **Was the system known-good then, or merely not-yet-complaining?** Nobody captures a baseline the week after an incident; they capture it when things are quiet, which is not the same as verified. 3. **Is its resolution finer than the symptom?** A quarterly capture cannot testify about a ten-second event. 4. **If this value had always been wrong, would this baseline look any different?** If the answer is no — and it usually is — then the match is not evidence about correctness, and saying so is the difference between a finding and a false negative. That last question is the whole article in one line, and it is worth asking aloud, because it is the one that turns a comfortable comparison back into an open investigation.