The Timeline Reconstruction: When Did It Start?
Why this matters
Half of a diagnosis is figuring out when the trouble began and what changed around that moment. A symptom that started the day after a repair points one direction. A symptom that crept in over months points another. If you skip the timeline you end up chasing the loudest complaint instead of the actual cause, which burns labor and sometimes leads to swapping a good part. This article is the intake method: how to reconstruct the timeline before you put a meter or a wrench on anything.
Start with the first occurrence, not the worst
People describe the worst day, not the first day. "It quit completely Tuesday" is the headline, but the unit may have been hinting for weeks. Ask directly: "When did you first notice anything off, even something minor you brushed aside?" Then ask what that early sign was. Intermittent before constant, quiet before loud, slow before failed. The earliest sign is usually closest to the root cause; the worst day is just where it crossed a threshold the customer could no longer ignore.
Write down two separate dates: first noticed and got bad enough to call. The gap between them tells you whether this is a slow degradation or a sudden break.
Anchor the start to a known event
A bare date means little. Tie the onset to something the customer remembers, because memory attaches to events, not calendars. Walk through the common anchors:
- A repair or service visit. "Did anyone work on it recently, even something unrelated?" A fault that appears right after service usually traces to that service: a connection left loose, a setting changed, a part disturbed.
- A power event. A storm, an outage, a breaker that tripped, a generator transfer. Electronics and controls often misbehave only after a power blip.
- A weather or season change. First cold snap, first heat wave, the day the humidity climbed. Many faults are temperature or load dependent and only show up at one extreme.
- A usage change. New occupant, heavier use, a long vacancy, something moved or added nearby.
- A physical event. Something was bumped, flooded, renovated near, or had work done in the same area by another trade.
If the onset lines up tightly with one of these, you have a prime suspect before you open anything.
Map the pattern, not just the start
Once you have the start, characterize how the symptom behaves over time. The shape of the pattern narrows the cause more than the symptom itself.
- Constant since it started suggests a hard failure or a setting that got changed once.
- Intermittent and random suggests a loose connection, a marginal part, or thermal expansion.
- Tied to time of day (worse in the morning, fine by afternoon) suggests temperature, condensation, or a component that needs to warm up.
- Tied to runtime (fine on startup, acts up after running a while) suggests heat buildup, a part drifting as it warms, or something that only loads up under sustained operation.
- Getting steadily worse suggests wear, a slow leak, fouling, or a part on its way out.
- Step change (fine, then abruptly different) suggests a single event: a part let go, a setting moved, a power hit.
Ask: "Is it getting worse, staying the same, or coming and going?" That one question routes you to a whole family of causes.
Separate what changed from what coincided
Not everything that happened near the onset caused it. Two things can change in the same week by chance. Your job is to rank by mechanism, not by timing alone. For each candidate event, ask whether there is a plausible path from that event to this symptom. A power outage can plausibly scramble a control; a new coat of paint in the next room usually cannot affect a buried valve. Keep the events that have a believable mechanism near the top and park the coincidences.
When two events both have a plausible mechanism, test the cheaper and more reversible one first.
Capture it in writing before you touch the unit
Do the timeline at the truck or the doorway, before you start disassembly, because once you are elbow-deep you will fixate on what is in front of you. A short written intake beats memory:
- First noticed (date and what the early sign was).
- Got bad (date and what crossed the line).
- Anchor events near the onset (repair, power, weather, usage, physical).
- Pattern (constant, intermittent, time-of-day, runtime, worsening, step change).
- Anything tried already by the customer or another tech.
This record also protects you. If the fault returns, the next visit starts from data instead of a fresh guess, and you can see whether your fix actually moved the timeline.
Turn the timeline into a first move
The timeline is not the diagnosis; it is the order of operations. Let it pick where you put the meter first:
- Onset right after service: re-inspect that service before anything else.
- Onset after a power event: check controls, settings, and protective devices first.
- Time-of-day or runtime pattern: plan to observe the unit in the condition that triggers it, not in a cold or idle state where it behaves.
- Slow worsening: head for wear, fouling, or a slow leak rather than a single failed part.
A good timeline turns a vague complaint into a ranked list of where to look. That is the whole point.
References
- See related: The Setting Drifted vs the Part Failed Decision Tree
- See related: The Fault After a Power Blip Decision Tree
- Trade-standard diagnostic practice: structured customer intake and symptom history before disassembly