Intermittent faults are the ones that generate second and third visits. The machine runs fine while the technician is there; the alarm returns on the night shift. The operator's description is "sometimes". And the controller has been logging every alarm with a timestamp for two years, in an export nobody opens because it is 400 lines of codes.
What is in the log
Timestamps. Alarm codes. Often the axis, the active program, the speed or load at the moment. Sometimes operator acknowledgements. That is enough to answer the questions a diagnostician would ask: which shift, which axis, what was the machine doing, what happened just before.
Clustering
Seventeen occurrences of a servo overcurrent in thirty days. All on axis 2. All at rapid traverse above 20 m/min. All after more than two hours of running. Nothing on axes 1 and 3. That pattern — speed-dependent, warm-up-dependent, single axis — points away from the drive and toward something mechanical or a cable that moves with the axis. Two closed work orders on the same model show the same pattern and resolved as cable-carrier wear causing an intermittent short.
A help-desk agent with that summary can ask the operator to check one thing by phone before anyone drives anywhere.
Cascades
The other thing the log settles is order. The operator reports a drive fault; the log shows coolant flow low thirty seconds earlier, spindle temperature high ten seconds after, then the drive fault, then the e-stop. The drive is the last domino. Ordering alarms by timestamp before building the checklist is a small step that prevents a common wrong repair.
Why this is a product feature and not a data-science project
Because it runs on the export the controller already produces, with no instrumentation project, for a single machine, at the moment of the call. Predictive maintenance across an instrumented fleet is a different and larger thing. This is just reading the log — which, it turns out, nobody was doing.