Troubleshooting
Was it the update? Direction is the evidence
Something worked yesterday and does not today. The honest answer is not “it is probably the update” — it is to look at which came first.
Direction matters
A failure that follows an update is the classic “after updating” story. A failure that precedes the update cannot be blamed on it, no matter how tempting that is. Before you attribute anything, put the two timestamps side by side. In practice that one comparison removes a large share of wrong accusations — in both directions.
“OK” must be a positive confirmation
There is a trap in how a diagnosis reports success. If “ok” means we found no problem, then a rule that never ran looks exactly like a healthy machine. The three states should be:
- ok — we checked, and it is explicitly fine. Not an absence of data.
- notice — worth a look, not a defect.
- warning — a concrete problem.
Keeping “ok” positive is what stops an empty result from reading like a clean bill of health.
Read a snapshot, not live state
A conclusion should come from a frozen snapshot of everything the rules are allowed to read. If a rule can reach into live state while it runs, the answer depends on what changed halfway through the analysis — and the same machine can produce two different conclusions minutes apart with nothing having happened in between. Plain values in, one conclusion out.
Two subtle counting bugs
- The same warning recorded under two languages is one problem, not two. Group on a stable kind when the record carries one; otherwise a bilingual log looks like double the trouble.
- A name that cannot be parsed is unknown, never a guessed name. A wrong attribution is worse than an empty one, because it sends you looking in the wrong place.
What to do in practice
- Write down the exact time the problem started before you try fixes — every later action destroys the evidence.
- Compare it against update times, not against your memory of them.
- If the problem predates the update, stop trying to roll back and look at what else changed: a cable, a dock, a display, a macOS point release.
Honest limits
- Timestamps only order events. They do not prove causation — a failure after an update can still come from a loose cable that happened to move at the same time.
- A snapshot makes a conclusion reproducible, not correct. A rule with a bad threshold will reproduce the same wrong answer perfectly.