Repair Work Order Template
One record for a single breakdown, from the moment the asset stopped to the moment it ran again. It carries a timestamped downtime timeline, the fault found and its failure category, the root cause, and the parts and labour that together tell you whether to repair this asset again or replace it.
- Downtime timeline, stop to back-in-service
- Failure category and root cause, not just the fix
- Was this preventable, answered on the form
- Repair cost against replacement, on one page
Repair Work Order
Breakdown record, downtime and root cause
| # | Work performed | Done | Hrs | Notes |
|---|---|---|---|---|
| 1 | Log the stop time, not the report time | |||
| 2 | Record the symptom as reported, and what the asset does | |||
| 3 | Make safe and note who isolated it, and when | |||
| 4 | Timestamp each downtime event as it happens | |||
| 5 | Diagnose: fault found, failure category, root cause | |||
| 6 | Answer whether it was preventable, then close out |
A preview of the real document. The download is the complete file.
Download the repair work order template
Free, editable and yours to rebrand. Pick a format. You'll get all three, so you have the printable version too.
- Word (.docx) for editing the failure categories and adding your own terms.
- Excel (.xlsx) where the downtime hours, parts, labour and repair total calculate themselves.
- PDF print-ready, for the signature on site.
Who this repair work order is for
Four people read this document, and each of them wants a different line out of it.
Facilities manager
You are answering how long the asset was down and whether it will go again. The downtime summary and the root cause are the two entries that tell you whether this is a fix or a countdown.
Maintenance planner
You are deciding what to schedule and what to stock. Failure category, the preventable question and the parts used are what turn this repair into a PM task or a stocked spare.
Repair technician
You are the one filling it in, usually under pressure. The isolation row and the tests performed protect you: they record that the asset was made safe and that the repair was proved, not assumed.
Finance or asset owner
You are weighing repair against replacement. Cost of downtime per hour, the repair total and the count of previous failures on the same asset are the three figures that decide it.
Where a repair work order is used
The document is the same shape everywhere. What changes is which fields carry the weight.
| Setting | What the form has to capture there |
|---|---|
| Manufacturing | Downtime is measured in lost output. Cost of downtime per hour and the stop-to-restart gap matter more than the parts line. |
| Commercial property | Tenant impact and SLA. Target repair by, the temporary workaround and whether the asset was left degraded or fully restored are the load-bearing fields. |
| Healthcare | Traceability of the repair. Tests performed and results, the isolation record and the sign-off have to survive an audit years later. |
| Retail | Trading hours. Whether a workaround kept the store open, and how long the asset ran degraded, decide whether the repair was acceptable. |
| Fleet and equipment hire | Cost per asset. Repeated failure references and the running repair total against replacement cost are what end a machine's service life. |
What a repair work order should include
A repair work order is the record that authorises a corrective fix to a broken asset and documents what failed, why, and what it cost. It names the asset, timestamps the downtime, records the fault found and its root cause, and closes with the parts, labour and the evidence behind repairing rather than replacing.
Fields every work order needs
- Work order number
A unique reference, e.g. RWO-2026-0733
- Date and time raised
When the request came in, not when you got there
- Priority
Set at intake, from the contract, before anyone forms a view
- Site and location
Where the work happens, precise enough to find unaided
- Raised by and contact
Who asked, and how to reach them on arrival
- Target completion
The time you are committed to, so the SLA is measurable
- Parts and materials
Item, quantity, unit price and who it is charged to
- Labour
Date, who attended, hours and rate
- Sign-off
Both signatures, named and dated
Fields specific to a repair work order
| Field | What goes in it | Why it earns its place |
|---|---|---|
| Failure severity | Total breakdown, degraded but running, safety risk or cosmetic | Decides dispatch before anyone has seen it. Degraded but running is the category that gets under-reported and then fails completely. |
| Downtime timeline | Asset stopped, fault reported, technician on site, diagnosis complete, parts available, repair complete, back in service | The page's whole argument. Seven timestamps show where the hours went, and the gap between reported and on site is your response time rather than an assertion. |
| Downtime summary | Total hours out of service, cost of downtime per hour, cost of downtime | Turns hours into money. Without a rate per hour, downtime stays an inconvenience instead of a number a replacement case can use. |
| Fault found and failure category | Wear, fatigue, corrosion, electrical, contamination, overload, operator error, design or unknown | One word that makes repairs countable. Ten corrosion failures on one line is an environment problem, not ten separate jobs. |
| Root cause | What actually caused the failure, not the part that broke | A snapped belt is a symptom. Misalignment is a cause. Only the second one can be designed out. |
| Was this preventable | Yes or no, and what would have caught it | The single most valuable field on the form and the one most often skipped. It is where reactive work turns into a PM task. |
| Failed before | Yes or no, with the previous work order reference | Links this event to the asset's history. Three references in a year is a replacement conversation, not a repair. |
| Asset isolated or made safe | By whom and when, plus any temporary workaround | Safety evidence, and the record of what the site was running on while the asset was down. |
If you cut the form down, keep the downtime timeline. It is the difference between knowing an asset was down for a shift and knowing that six of those hours were spent waiting for a part nobody stocked. One number tells you there was a problem; the timeline tells you which problem to fix.
What it looks like filled in
A real breakdown, filled end to end. This is the same job the Excel version totals for you.
| Downtime event | Date | Time | Recorded by | Elapsed |
|---|---|---|---|---|
| Asset stopped | 18/09/2026 | 06:40 | Night shift lead | n/a |
| Fault reported | 18/09/2026 | 06:52 | Night shift lead | 0h 12m |
| Technician on site | 18/09/2026 | 08:15 | D. Osei | 1h 35m |
| Diagnosis complete | 18/09/2026 | 08:50 | D. Osei | 2h 10m |
| Parts available | 18/09/2026 | 11:20 | Stores | 4h 40m |
| Repair complete | 18/09/2026 | 12:35 | D. Osei | 5h 55m |
| Asset back in service | 18/09/2026 | 13:05 | Production | 6h 25m |
Work order RWO-2026-0733, conveyor drive unit CNV-04. Fault found: drive-end bearing seized, shaft scored. Failure category wear; root cause misalignment after the last belt change. Preventable, yes: an alignment check on the PM would have caught it. Parts: bearing BRG-6206-2RS, two at 14.25. Labour 3.75 hours. Read the elapsed column and the answer is obvious: the repair took just over an hour, and the other five were waiting.
How do you fill in a repair work order?
Fill it in the order the breakdown happens, and timestamp each event as it occurs rather than reconstructing them afterwards. Six steps, and the fourth is the one that gets skipped.
Log the stop time, not the time you were told
Date and time reported, plus who reported it and how. The stop time is what the downtime clock runs from, and it is usually earlier than the phone call.
Describe the symptom, and what the asset does when it fails
Along with when it was first noticed and whether it has failed before. This is the evidence that separates a one-off from a pattern.
Make it safe before you diagnose it
Record who isolated the asset and when, and note any temporary workaround the site is running on. This row is the one an incident investigation reads first.
Timestamp every downtime event as it happens
Reported, on site, diagnosed, parts available, repaired, back in service. Filled in later from memory these collapse into two entries and the waiting disappears.
Name the failure category and the root cause separately
The part that broke is not the reason it broke. Then answer whether it was preventable, and what would have caught it.
Total the downtime and the repair, then decide
Hours out of service against cost per hour, parts and labour against replacement cost, and the count of previous failures. Close with both signatures.
Repair work order vs replacement decision
The same document answers both questions, but they are not the same question. One authorises work; the other ends an asset's service life.
| Aspect | Repair work order | Replacement decision |
|---|---|---|
| What it is | Authorisation and record for one corrective fix | A judgement about whether to keep fixing this asset at all |
| Time span | One event, hours or days | The asset's history, usually a year or more |
| The load-bearing fields | Fault found, root cause, parts, labour, downtime | Repeated failure references, running repair total, downtime cost, remaining life |
| Who signs | Technician and the person accepting the work | Whoever owns the capital budget |
| What it produces | A working asset and a cost line | A capital request, or a decision to run to failure |
| Where it goes wrong | Closing without a root cause, so nothing is learned | Made on a feeling, because nobody totalled the repairs |
In practice the replacement decision is only as good as the repair records behind it. An asset with six repair work orders, each closed with a root cause and a downtime cost, makes its own case. The same asset with six work orders closed as fixed, no cause recorded, produces an argument instead of evidence.
Where a document stops working
A form handles one breakdown well. It handles an estate of assets badly, and the failure modes are consistent.
There is no version control
Somebody edits the failure categories, emails the form round, and two versions are in use on the same site. Nothing tells you which repair used which.
The downtime clock isn't running
Target repair by sits on a sheet. Nothing warns you an hour before it breaches, which is the only moment the information could change the outcome.
There is no audit trail
A signed sheet proves a signature existed. It cannot show that a root cause was added a week later, or by whom, which is the question an investigation asks.
You cannot total the asset
One form describes one failure. Which asset has failed most often, and what it has cost in downtime, exist only across forms, and a folder will not add them up.
What running this in Facilio looks like
The template is the paper version of this record. The fields below are the same ones; the difference is that they become state the platform can act on.
Work Completion Validator
Root cause becomes a condition of closing
On paper, a repair is complete when someone signs it. Work Completion Validator checks the completion record against what the job required, so a repair closed with no root cause and no preventable answer is caught while the technician is still on site.
Ops Performance Intelligence
The downtime timeline becomes a live clock
The same timestamps you write by hand drive an SLA that can warn before target repair by breaches, and roll up so you can see which assets and which sites are running hot rather than finding out in a quarterly review.
Audit Report Intelligence
Isolation and test results become retrievable evidence
Who made the asset safe, when, and what tests proved the repair, logged once against the asset and assembled into the report an investigator asks for instead of being searched for across a year of sheets.
Contractor Work Tracker
Repairs total themselves against replacement
Every part with a charge-to and every labour line at an agreed rate become the running repair cost for that asset, next to its downtime cost, so the replacement case is built from records rather than assembled in a hurry.
Audit-trailed. Every answer Atom AI gives traces back to the record it came from, so a claim in a report can be followed to the visit that produced it.
Frequently asked questions
What is a repair work order?
A repair work order is the record that authorises a corrective fix to a broken asset and documents what happened. It captures the reported symptom, the downtime timeline, the fault found and its failure category, the root cause, the parts and labour used, and a signature accepting the work.
It differs from a general maintenance work order in what it has to prove. A maintenance visit records that tasks were performed. A repair has to establish why something failed, because that is what stops it failing again.
What should a repair work order include?
At minimum: a unique work order number, the date and time reported, failure severity and priority, the site and asset ID, the symptom as reported, a timestamped downtime timeline, the fault found, the failure category, the root cause, whether it was preventable, whether the asset has failed before, the parts and labour, and both signatures.
Why record a downtime timeline instead of total hours?
Because a single figure hides the cause. Six hours out of service tells you there was a problem. A timeline showing twelve minutes to report, eighty-three to attend, and two and a half hours waiting on a part tells you which problem to fix.
The gap between fault reported and technician on site is your response time. The gap between diagnosis and parts available is your stores performance. Neither is visible in a total.
What is the difference between failure category and root cause?
Failure category is a fixed word from a short list, which makes repairs countable: wear, fatigue, corrosion, electrical, contamination, overload, operator error, design or unknown. Root cause is the sentence explaining this specific failure.
You need both. The category lets you see that corrosion accounts for most failures on one line. The root cause tells you it is a leaking roof above it.
Should I record whether a failure was preventable?
Yes, and it is the field most often left blank. Answering it honestly is the mechanism by which reactive work becomes planned work.
A yes with what would have caught it is a PM task waiting to be written. A no is equally useful, because it stops you adding checks that would not have helped.
When does a repair work order become a replacement case?
When the records say so rather than when someone loses patience. Three fields carry it: the count of previous work orders on the same asset, the running repair total, and the cost of downtime per hour multiplied by the hours lost.
Kept properly, the repair records build the case themselves. Kept as signed sheets with no cause recorded, they produce an argument instead.
Can I edit and rebrand this template?
Yes. It is free to use, edit, rename and put your own logo on, internally or for clients. No attribution required.
The Word version is the one to edit if you want to change the failure categories or the wording; the Excel version is the one to use if you want the downtime hours, parts and labour to total themselves.
In one paragraph
A repair work order records one breakdown on one asset. Log the stop time rather than the report time, make the asset safe before diagnosing, and timestamp each downtime event as it happens. Name the failure category and the root cause separately, then answer whether it was preventable and what would have caught it. Close with the downtime total, parts, labour and both signatures. Kept this way, the repair records build the replacement case on their own.
The template is the floor, not the ceiling
A document records one breakdown. A connected CMMS runs the estate: downtime that totals itself, root causes that become PM tasks, and repair history that makes the replacement case without anyone assembling it.
