The technical side of fault-finding is well covered elsewhere. The part that actually decides how long a breakdown lasts is procedural, and it is rarely written down.
Back up before you change anything
Upload the running program and save it, labelled with the date, before making a single edit. This is the difference between “we can put it back exactly as it was” and an afternoon of trying to remember. It takes two minutes and it has saved every engineer who does it at least once.
Change one thing at a time
Two changes at once and a fault that disappears tells you nothing about which change fixed it — and if the fault returns next month you have learned nothing at all. One change, observe, record. It feels slower and it is faster.
Write down what you changed, as you change it
Not afterwards from memory. A running list of what was modified, where, and why is what lets you reverse cleanly if the direction turns out to be wrong. It is also what the next engineer needs.
Ask when the fault started and what changed then
Machines rarely develop faults spontaneously. Something changed: a product, a setting, a part replaced, a shift pattern, the weather. The answer is often in the answer to “what was different that week”, and the operators know even when nobody has asked them.
Distinguish the fault from the symptom
The alarm tells you where the machine noticed the problem, not where it originated. A conveyor jam alarm may be a sensor, a product change, an upstream timing issue, or a genuine jam. Following the alarm to its source rather than treating the alarm itself is what separates a fix from a temporary reprieve.
Be careful with forces
Forcing an I/O point is a legitimate diagnostic tool and a genuine hazard. Anything forced must be written on a list and removed before you leave, and nothing that commands motion should be forced while somebody could be inside the guarding. Forces left in place have caused injuries.
Know when to stop
If two hours of investigation have produced no narrowing of the possibilities, stop and get a second opinion rather than starting to change things speculatively. Speculative changes are how a fault that was understood becomes a fault that is not.
Close it out properly
Remove forces, restore any temporarily disabled interlocks, upload and archive the final program, and write down what the cause actually was. That last step is what stops the same fault costing the same hours next year.