Article
"It's Running Now" Is Not a Fix: Leave a Trail the Next Tech Can Find
"It's running now" isn't a fix. The six things to write at close-out so the next technician can find what worked when the same machine goes down.
Short answer: "It's running now" tells the next technician nothing. Before you close a breakdown job, write down six things: the fault code exactly as displayed, the model and serial, the trip conditions, what you tried, what actually worked, and the parts used. It takes minutes, and the next repeat fault becomes a search, not a fresh diagnosis.
What goes wrong when the job card just says "it's running now"?
The machine trips. Production is waiting. You reset it, reseat something, and it runs. The job closes with one line.
Charles Baxley described what happens next in a public LinkedIn post that opens with "One of the worst answers you can hear after a breakdown is: 'It's running now.'" He admits he's done it too: "You're buried, production needs the machine, you find something that gets it going and everybody moves on to the next problem." Then:
"Then three days later the same machine goes down. 'What did we do last time?' Nobody remembers." (Charles Baxley, public LinkedIn post)
He adds a second failure that is easy to miss: "Or worse, we remember what we did but still don't know why it worked." And he names the record that causes it: a troubleshooting history that is "basically 'reset machine, ran okay.'"
The fix may well have worked. The record of it didn't, so the next technician starts again from the manual's cause list.
Why does a missing write-up turn into a repeat breakdown?
A repair that wasn't written down can't be looked up, so it can't stop the next breakdown. Delin S. put it in one line in a public LinkedIn post about machines that keep breaking:
"A repair you cannot look up is a repair you are likely to repeat." (Delin S., public LinkedIn post)
In the same post he lists what happens when repair history "lives on paper, in scattered files, or in someone's head": repeat failures go unnoticed, "Root causes never get properly named", and "Technicians start from zero every time."
Łukasz Kincel makes the same point from the search side in a public LinkedIn post about a fix "buried in a service report nobody can search":
"The hard part is your repair history: free-text reports, mixed languages, photos without context. Search can only be as good as what it searches." (Łukasz Kincel, public LinkedIn post)
That last sentence is the case for a better close-out. No search tool or senior colleague can recover a detail that was never written, and the only moment all the facts are known at once is when the job closes.
What should you write before you close the job?
Write these six fields in the service report or job card while you're still at the machine.
| Field | What to write | Why the next tech needs it |
|---|---|---|
| Fault code | The code exactly as the display or HMI showed it, plus its plain-language name | People search by the code on the display. "Drive tripped" won't match it. |
| Model and serial | Make, model, rating, serial number, and firmware if you can see it | The same code can mean a different usual cause on another unit. The serial links this visit to earlier ones. |
| Trip conditions | When it trips (power-up, on start, under load, after a run time), what changed just before, and whether it clears on reset | This is the clue that narrows the cause, and it's the first thing lost from memory. |
| What was tried | Every check and action, in order, with readings, including the ones that didn't help | A ruled-out cause saves the next tech the first hour. |
| What worked | The action that cleared the fault, kept separate from the cause. If you don't know why it worked, write "cause not confirmed" | It avoids Baxley's "don't know why it worked" problem and tells the next person to dig further. |
| Parts | Part names and numbers fitted and removed, and where the removed part went | Shows whether the same part keeps failing on that serial or model. |
In India these go on the job card or AMC service report; in the US, on the work order or field service report. The fields are the same.
What does a findable write-up look like next to "reset, ran okay"?
Here's a public case. On the Siemens Industry Online Support forum, a technician wrote: "THE FAULT F0001 IS CONTIOUSLY COMES ON 18.5 KW MM440 DRIVE,RESET THE FAULT FROM BOP BUT PROBLEM REMAIN SAME". The fix eventually came from a different user in an older, linked thread: "I disconnected all connectors from CPU card to base board and connected again-----> the controller(my MM440) is OK now!!" We walked through that thread in how to find the last fix that worked for a repeat machine fault.
Put those public details into the six fields and compare:
| Field | One-line close-out | Six-field close-out (from the public thread) |
|---|---|---|
| Fault code | "Drive fault" | F0001 (overcurrent) |
| Model and serial | Not recorded | Siemens MICROMASTER 440, 18.5 kW. Serial: not in the public post, but it belongs in your own report |
| Trip conditions | Not recorded | Comes back continuously. Reset from the BOP doesn't clear it |
| What was tried | "Reset" | Reset from the BOP: no change |
| What worked | "Ran okay" | Disconnected and reconnected all connectors between the CPU card and the base board |
| Parts | Not recorded | None reported for that fix |
In the thread, it took a second user who happened to remember the older post to connect the two. A six-field write-up lets a plain search do it.
Isn't a full root cause analysis too much for every breakdown?
Yes, and you don't need one. Baxley says it plainly in the same post: "Not every breakdown needs a three-hour RCA meeting. Sometimes a loose wire really is just a loose wire."
The close-out write-up isn't an RCA. It's the minimum record that lets someone find this job later. A loose wire still gets six short fields: the code, the machine, when it tripped, what you checked, which terminal was loose, and "no parts."
The full analysis is for the faults that come back, and you only spot those if earlier visits were written up. Three reports on one serial that all say "reset, ran okay" don't show it's the same fault three times.
How do you make the write-up a habit at close-out?
Make the write-up part of closing the job, not a task for later. Use this checklist before you sign off:
- Close out at the machine. Fill in the six fields before you leave, not at the end of the shift.
- No empty fields. If something wasn't checked or isn't known, write "not checked" or "cause not confirmed." A blank looks like nothing happened.
- Copy the code, don't describe it. Write F0001, not "overcurrent fault" alone.
- List what didn't work. One line per check, with the reading.
- Keep "what worked" and "why" apart. Write the action. Write the cause only if you confirmed it.
- Caption every photo. Say which unit, which board, and what the photo shows. Kincel's "photos without context" are hard to use later.
- Put it in the report that gets filed. A WhatsApp message or a ticket that only says "resolved" won't be there for the next tech.
- Add a follow-up line. If the fault returns, add to the same record instead of starting a new story.
For supervisors, the simplest change is a report form that won't close with "what was tried" or "what worked" empty. As Baxley's post ends: "Leaving something useful behind for the next guy is part of it too."
Where does HangerSearch fit?
A write-up only helps if someone can find it. HangerSearch is private, retrieval-only search over your team's own finalized service, test and inspection reports. You search by fault code, model or symptom. It shows the few prior cases that match and why each matched, and opens the cited page. Nothing is generated, and if there's no similar report, it says so. See how we handle your reports.
Book a 20-minute demo: hangersearch.com
FAQ
What should a technician write after fixing a breakdown?
Six fields: the fault code exactly as displayed, the model and serial, the trip conditions, what was tried (with readings), what actually worked, and the parts fitted or removed. If the cause isn't confirmed, say so. Write it at the machine, before the job is closed.
Why is "it's running now" not enough on a service report?
It records the outcome, not the fault, the machine, the checks or the fix. When the machine goes down again, the next technician has nothing to search and starts over from the manual.
Do we need a root cause analysis for every breakdown?
No. Most need a short six-field write-up. Those write-ups show which faults keep returning, and those are worth a proper root cause analysis.
What if we don't know why the fix worked?
Write what you did and mark the cause as "not confirmed." That's more useful than a guess, and it tells the next technician the root cause is still open.
Sources
- Charles Baxley, public LinkedIn post, "One of the worst answers you can hear after a breakdown is: 'It's running now.'" (2 Sep 2026): https://www.linkedin.com/posts/charles-baxley80_one-of-the-worst-answers-you-can-hear-after-activity-7500832090196758528-GACa
- Delin S., public LinkedIn post, "Maintenance keeps fixing, but the same machine keeps breaking." (11 Oct 2026): https://www.linkedin.com/posts/delinsirkov_maintenance-cmms-reliability-activity-7514852511011463168-0mhw
- Łukasz Kincel, public LinkedIn post, "Your technician is in a plant basement. No signal." (9 Oct 2026): https://www.linkedin.com/posts/lukasz-kincel_your-technician-is-in-a-plant-basement-no-activity-7514242153645203456-ubdP
- Siemens Industry Online Support forum, "F0001 CONTINUOSLY COMES ON MM440 DRIVE" (thread started 18 Mar 2013): https://support.industry.siemens.com/forum/gb/en/posts/f0001-continuosly-comes-on-mm440-drive/89116