Features
Part of Repair diagnosis guide: define the fault before paying for parts
Intermittent laptop failure: a worked diagnosis and repair decision
Intermittent laptop failure case showing how a fictional owner logs shutdowns, controls variables, reads diagnostics, compares repair quotes, and verifies work.
What to take away
- This fictional case demonstrates method, not a diagnosis for another laptop.
- A timestamped log exposes patterns that a one-time bench test may miss.
- Changing one condition at a time prevents a false conclusion.
- Built-in diagnostics and event records narrow possibilities but need interpretation.
- A repair succeeds only when the original symptom is tested under the original conditions.
Maya owns a four-year-old laptop that shuts down without warning. It may run for hours at a desk, yet sometimes turns off during a video call. The computer restarts normally and shows no obvious error. She needs it for contract work, so lost time and data matter as much as the part price.
This is a fictional worked example. Product-specific instructions, safety conditions, warranties, and evidence differ.
Day 1: replace the guess with a record
Maya's first guess is a failing battery. She does not order one. She writes a neutral symptom statement: "The laptop loses power instantly, with no shutdown screen, during some video calls. It restarts using the power button." That sentence already follows the repair diagnosis guide: behavior, conditions, reproduction, and no cause baked in.
She starts a log:
| Time | Power | Battery | Activity | Surface | Accessories | Result |
|---|---|---|---|---|---|---|
| 9:10 a.m. | charger | 82% | hard desk | dock | normal | |
| 11:42 a.m. | charger | 100% | video call | hard desk | dock | instant off |
| 2:30 p.m. | battery | 71% | documents | hard desk | none | normal |
| 4:18 p.m. | charger | 96% | video call | lap | headset | instant off |
She records the model, firmware, operating-system version, charger rating, and dock model. She photographs the vents and checks for swelling, odor, liquid evidence, damaged cables, and unusual surface heat. There is no visible battery deformation or other condition that calls for immediate hazardous-device handling.
Day 2: protect data and preserve evidence
Maya copies her work files, photographs, local mail archive, and password-manager recovery material to controlled destinations. She opens a sample from the backup. She saves screenshots of software versions and photographs the serial number.
She avoids a factory reset because the current state may contain logs. She does not update several drivers, replace the battery, clean the operating system, and change the charger at once. That would make any improvement hard to interpret.
Day 3: control conditions
Maya creates a repeatable 30-minute call test. She first removes the dock while keeping the same charger, desk, network, and workload. The computer still turns off on the second run. She then uses the maker-approved charger with no headset. The fault appears again.
Next she places the laptop on a hard, open surface and records fan behavior. The fault takes longer but returns under sustained load. She does not block vents to provoke it. The timing suggests that load or temperature may matter, but it does not prove which component is at fault. The laptop overheating problems guide explains why heat evidence needs that caution.
Day 4: collect device evidence
The laptop's maker provides a built-in hardware test. Maya follows the exact model instructions, records the result, and photographs the reference code. A quick test passes. She understands that one passing run cannot rule out an intermittent fault.
She also checks what the firmware itself recorded. A computer's power-on self-test runs before the operating system every time the machine starts, and its error codes can be shown on screen, stored for later retrieval by a diagnostic tool, or signaled as light or beep patterns when the display is out of action. Maya's fictional machine holds two stored thermal entries that align with her log. This evidence raises a testable lead; it is not a final parts list.
Day 5: ask for a bounded diagnosis
Maya gives a repairer the laptop, charger, symptom statement, timestamps, photographs, test code, and event record. The repair intake checklist is the fuller version of this hand-off. The intake says:
- diagnostic fee: $45
- no parts without written approval
- maximum pre-approved total: $45
- data erasure and storage replacement: not authorized
- target test: sustained video workload on AC power
- included items: laptop and labeled charger
The technician reproduces the shutdown, checks cooling performance, and finds that the fan sometimes fails to start. Inspection shows debris and a worn fan bearing. The battery passes the shop's model-appropriate test. The written proposal includes cleaning, fan replacement, labor, tax, the part condition, and a 90-day warranty on the repair. That is what a healthy quote looks like; the repair quote problems guide catalogs the other kind.
Compare the options
Maya records the three real choices:
| Choice | Immediate cost | Downtime | Expected result | Main uncertainty |
|---|---|---|---|---|
| Decline after diagnosis | $45 | 1 day | laptop still unreliable | replacement setup needed |
| Approve fan repair | $165 total | 3 days | specific confirmed fault treated | other aging parts remain |
| Replace laptop | $890 plus setup | 2 to 5 days | supported new system | migration and accessory fit |
She checks the device's remaining software support, current working value, replacement compatibility, and her recent backup. The upgrade, repair, or replace decision formalizes exactly that comparison. She approves the bounded repair because the shop reproduced the fault and tied its proposal to evidence.
Verify instead of assuming
At collection, Maya matches the serial number and checks the case, ports, screws, charger, and invoice. The technician identifies the installed fan and shows the completed test record.
Maya repeats the original video-call workload on AC power, then checks battery operation, charging, sound, camera, network, sleep, wake, and fan behavior. She runs the maker's hardware test again and records the code. Methodical troubleshooting treats an intermittent symptom as the hardest kind: the discipline is to reproduce the original conditions, change one variable at a time, and accept that a fault which fails to appear once is not yet proven gone.
She keeps the backup and continues the same timestamped log for two weeks. The shutdown does not return across twelve controlled calls. That supports the repair result more strongly than a few minutes of idle use at pickup.
What the case does not prove
It does not prove that all sudden shutdowns are thermal, that a fan should be replaced after any thermal event, or that a passing battery test settles every power fault. It shows how observation, controlled tests, device records, a written scope, and post-repair verification can turn an intermittent complaint into a defensible decision.
Common questions
Why did Maya not replace the battery first?
The observed fault did not establish battery failure, and it occurred on external power. Testing before purchasing limited waste and confusion.
Why keep testing after the repair?
An intermittent symptom can disappear temporarily. Repeating the original workload over time provides better evidence.
Could software still have caused the shutdown?
Yes at the beginning. The controlled reproduction, aligned event record, physical fan finding, and successful post-repair tests made the confirmed cooling fault the stronger explanation in this fictional case.
When should an owner stop testing?
Stop when there is a safety hazard, risk to irreplaceable data, required live electrical work, or a step outside the owner's tools and competence.
