Why Jake Documents Startup Like a Crash Report (And What He Writes Dow

0 comments

Most installers treat startup documentation like a receipt.

Model number.
Serial number.
Gas pressure.
Done.

I document startup like an aircraft crash report.

Not because I expect failure —
but because when something does happen months or years later, I want evidence, not opinions.

Startup documentation isn’t busywork.
It’s insurance.
It’s memory.
And it’s how I make sure I never argue with a furnace about what really happened on day one.

80,000 BTU 96% AFUE Upflow/Horizontal Single Stage Goodman Gas Furnace - GR9S960803BN

🧠 Why Startup Documentation Is More Important Than Installation Notes

Installs are visible.
Startup behavior is not.

Once the panels go on, nobody remembers:

How the flame looked
How fast the blower ramped
Whether the pressure switch hesitated
If the furnace struggled before stabilizing

Except the furnace.

And if you don’t write it down, you’re left guessing later.

Startup documentation captures:

Behavior, not just specs
Trends, not snapshots
Context, not assumptions

🚨 The “It’s Acting Weird” Call (And Why Notes Matter)

Every tech has heard this:

“It’s acting weird. It’s always done this… I think.”

That’s not a symptom.
That’s a memory problem.

Without startup documentation, you’re forced to:

Trust homeowner recollection
Trust your own assumptions
Trust that nothing changed

I don’t trust any of that.

I trust notes.

🧾 Why I Call It a “Crash Report”

A crash report answers four questions:

What was normal?
What changed?
When did it change?
Why did it matter?

That’s exactly how I document startup.

Not to prove I was right — but to establish baseline reality.

🔥 Section 1: Ignition Behavior (Not Just “Ignites”)

I never write:

“Ignition OK”

That tells me nothing later.

I write:

Ignition time (fast / delayed)
Carryover smoothness
Flame confidence
Any hesitation before stabilization

Why?

Because marginal ignition on day one often becomes intermittent ignition failure years later.

Honeywell’s combustion control documentation emphasizes that ignition behavior consistency is critical for long-term reliability

🌬️ Section 2: Blower Behavior and Airflow Feel

I document how airflow behaved, not just what it measured.

My notes include:

Ramp speed (smooth vs aggressive)
Noise character (whistle, rumble, neutral)
Cabinet vibration
Return pull consistency

Numbers can look fine while airflow feels wrong.

Those feelings become patterns later.

🌡️ Section 3: Heat Rise as a Trend, Not a Number

I never document one heat rise reading.

I document:

Time to stabilize
Initial reading vs final reading
Whether it crept upward
Whether it stayed consistent across cycles

That tells me:

If airflow was marginal
If timing mattered
If filters or ducts were borderline

The Air Conditioning Contractors of America (ACCA) stresses that airflow and temperature diagnostics must consider stabilization time and repeatability

💧 Section 4: Condensate Behavior (Observed, Not Assumed)

I don’t write:

“Condensate hooked up”

I write:

Trap primed
Drain flowing
No standing water
Condensate observed during run

Because later, when someone says:

“It smells weird when it runs,”

I already know whether condensate was behaving correctly on day one.

The U.S. Department of Energy has linked improper condensate management to premature failure in condensing furnaces:
https://www.energy.gov

⚠️ Section 5: Safety Response and Recovery

This is where crash-report thinking really matters.

If I test safeties, I document:

What was tested
How fast the system responded
Whether recovery was clean
Whether retries felt confident

I never want to wonder:

“Did it always do that?”

I want proof.

ASHRAE notes that safety response timing and recovery behavior are key indicators of long-term system reliability:
https://www.ashrae.org/technical-resources

🔄 Section 6: Cycle Consistency

One good cycle doesn’t earn trust.

I document:

Cold start behavior
Warm restart behavior
Whether cycles felt identical

If cycle two behaves differently than cycle one, that matters — even if no fault codes appear.

That inconsistency is often the first clue something will surface later.

🛠️ Tools Support Notes — They Don’t Replace Them

Yes, I use good tools.

But tools only capture moments.

Notes capture meaning.

🧾 What My Actual Startup Notes Look Like

They’re short.
They’re specific.
They’re boring to read.

And they save me hours later.

Examples:

“Ignition clean, no hesitation”
“Blower ramp smooth, no whistle”
“Heat rise stabilized after 18 min”
“Trap primed, steady condensate flow”
“No early lockouts, 3 clean cycles”

That’s not paperwork.

That’s context.

🏠 Why This Protects Homeowners Too

When something changes years later, documentation helps:

Prove something drifted
Avoid unnecessary part swaps
Identify real root causes
Reduce guesswork billing

Homeowners don’t want opinions.

They want answers.

🧠 Jake’s Rule on Startup Documentation

If it’s not written down,
it didn’t happen.

If it’s written clearly,
it becomes truth.

Startup documentation isn’t about covering yourself.

It’s about understanding the system when it was at its best.

🔚 Final Thought: Furnaces Age — Notes Don’t

Furnaces change.
Homes change.
Airflow changes.
Fuel conditions change.

Startup notes stay honest.

And when something eventually goes wrong —
because everything mechanical eventually does —
you won’t be guessing what the furnace was like when it was new.

You’ll know.

That’s why I document startup like a crash report.

Because when questions come later,
facts beat memory every time.