Torek Defect log software
Updated
A defect log is a continuous stream of entries about equipment faults: when, which unit, who found it, which assembly, how serious and how it ended. Its value is not the list itself but what the list makes visible — the faults that repeat and the ones that have been hanging open too long.
In Torek the log is filled in by the people who see the fault first: operators and drivers, on a phone, with a photo. The entry reaches the workshop immediately, and a work order is created from it in one step.
Almost every fleet has started one at some point. They stop for three reasons, and none of them is really about discipline:
| Question | What you can see |
|---|---|
| Which machine is the expensive one? | Faults and repair cost per unit over a period |
| Is this a repeat? | The same assembly on the same unit, more than once |
| What has been open longest? | Reported and closed dates on every entry |
| Are we maintaining in time? | Faults measured against planned maintenance |
| Who is falling behind? | Open entries counted per mechanic |
The second question usually pays off fastest. A recurring fault almost always means the symptom was fixed the first time and not the cause — and that is only visible when the history sits on the asset record rather than in a folder sorted by date.
The difference between a useful entry and a worthless one is specifics. Compare:
| Worthless | Useful |
|---|---|
| “Brakes are bad” | “Front axle, pad thickness 4 mm (limit 5 mm), disc cracked” |
| “Air leak” | “Trailer coupling, pressure drops from 8 to 5 bar overnight” |
| “Engine sounds odd” | “Cold start, smoke for 30 s, fault code P0402” |
In most cases a photo replaces the whole description, which is why in the mobile app it is attached in the same action rather than as a separate step. Photos taken against defects and jobs also collect on the asset record, so the machine ends up with a visual history nobody had to assemble.
A practical note: severity is worth setting at the moment of reporting, by the person reporting. Sorted later by someone who was not there, it turns into guesswork — and a queue ordered by guesswork is no better than an unordered one.
Duplicates and faults logged against the wrong machine happen in every log. The danger is when they can simply be deleted — then nobody can say where an entry went. Torek handles it like this:
A fault that already has a work order cannot be removed — the work order is dealt with first, so the job history never loses its starting point.
A fault can be reported in the browser, in the mobile app or at the workshop kiosk — every entry lands in the same log. The log is the entry point. An entry becomes a work order; the finished job becomes a line in the asset’s repair history with its parts and hours; and planned work does not wait for anything to break. Every day the system builds preventive-maintenance schedules from readings and rules, such as engine-hour intervals, and notifies the people responsible about what is coming up or overdue; a scheduled item becomes a work order in one step.
For every entry: the date and time, the asset, who reported it, the assembly or system affected, a description of the fault, a severity and what was done about it.
Without that last field the log becomes a list nobody closes — you can see that a fault existed, but not whether it was fixed.
For one yard and a handful of machines, entirely. The trouble starts once the equipment works in several places: entries stay where they were written, and the workshop hears about the fault late.
The second weakness is that paper cannot answer how many times the same fault has already come back.
The log is a continuous stream — every fault, in the order it was found. An inspection report is a one-off document describing the state of a machine at one moment.
In practice the report is usually assembled from the log entries made over a period, which is why the log has to be the thing people actually fill in.
Yes. The Android app stores the entry on the phone and syncs it when the signal returns — out on site that is often the deciding factor.
It can be removed, but not erased without a trace. Only the company administrator can remove an entry, and only with a reason; it disappears from lists, reports and search, but stays in the system with its comments and photos and goes into the removal log.
The administrator can restore a removed entry exactly as it was. A fault that already has a work order cannot be removed — the work order is dealt with first.
Whoever sees it first, which usually means operators and drivers rather than the workshop. Every entry records who reported it, so a log that is open to the whole crew does not become anonymous.
A walkthrough: from a phone on site to a closed job in the workshop.
Get in touch