Maintenance Log
One asset and its whole service history in a single register. Every job on it, planned, reactive and corrective, with what each one cost, so the question of whether to repair it again or replace it is answered from its own record rather than from somebody's impression of it.
- Lifetime spend read against replacement cost, calculated
- Planned, reactive and corrective in one register, not three
- A times-fitted count on every part, which is the early warning
- Reactive share per asset, so the bad actors surface
Maintenance Log
One asset, its whole life
| # | MAINTENANCE LOG | TYPE | HRS | COST |
|---|---|---|---|---|
| 1 | Quarterly service, filters and belts, no faults found | |||
| 2 | Reactive callout, unit tripped on high head pressure | |||
| 3 | Corrective, run capacitor replaced, third time fitted |
The document you will get. Download for the full, editable file.
Who this maintenance log is for
One asset, and three people who each read the same history for a different reason.
The technician who attended
You add a line per visit: what you did, how long it took, what parts went in. The parts detail is the part people skip and the part that pays, because the times-fitted count is built from it.
The maintenance planner
You read the reactive share and the recurring faults. An asset drifting toward reactive is telling you the interval is wrong, or that something upstream of it is.
Whoever signs off capital
You go straight to lifetime spend against replacement. It turns a replacement request from an opinion about an old unit into a ratio taken from its own history.
The next person to own the asset
Recurring faults, root cause where one was found, intervals already changed and spares worth holding. All the things that otherwise leave with whoever last worked on it.
Where an asset history earns its keep
The fields suit most serviceable equipment. What changes is how expensive downtime is and how hard replacement is to justify. If you run one of these, the sector page goes further than the template does.
- Data centers
Downtime hours are the column that matters, and a rising reactive share on critical plant is a capital conversation long before it is a maintenance one.
Data center maintenance software - Healthcare
Equipment with a clinical dependency, where repair-or-replace is decided on reliability rather than on cost alone.
Healthcare maintenance software - Retail and malls
Identical assets across many sites, where one unit's times-fitted count reveals whether the fault is the part or the installation.
Retail maintenance software - Commercial real estate
Plant inherited with a building and no history at all, which is the situation this log exists to end.
Portfolio maintenance software - Corporate facilities
Comfort plant where reactive callouts are visible to occupants, so the reactive share is also a satisfaction measure.
Corporate facilities software - FM service providers
Contracted assets, where the history is the evidence behind a recommendation to replace rather than keep repairing.
FM service provider software
What a maintenance log should contain
A maintenance log is the complete service history of a single asset, holding every job carried out on it in one register. It records planned, reactive and corrective work with hours, parts and cost, counts how often each part has been fitted, and reads total lifetime spend against what the asset would cost to replace today.
A. The sections that carry the weight
| Field | What goes in it | Why it earns its place |
|---|---|---|
| Asset details | What it is, where it is, its criticality and when it was installed | Install date is what turns spend into a rate. The same figure means something different on a three year old unit and a fifteen year old one. |
| Current replacement cost | What an equivalent asset would cost today | The denominator for the whole document. Without it the log records spending and cannot produce a decision. |
| The log itself | One row per job, with type, hours, parts, cost and who attended | Every job in one place regardless of type. The moment planned and reactive live in separate files, the reactive share stops being visible. |
| Work type per job | Preventive, reactive, corrective, inspection or modification | Five types rather than two, because a corrective job raised from an inspection is a different signal from an unplanned failure. |
| Work by type | A count against each type, calculated | Turns a list of jobs into a shape. Most assets look fine until you see what share of attention has been unplanned. |
| Reactive share | Reactive jobs as a percentage of all jobs on this asset | The single best indicator of whether an asset is being maintained or being rescued, and it only exists if both live in one register. |
| Lifetime hours and spend | Labor hours, parts, labor cost and contractor cost, totalled | Split so the reason for the spend is visible. An asset heavy on parts and light on hours is a different problem from the reverse. |
| Lifetime spend against replacement | Total spend as a percentage of current replacement cost | The row that gets an asset replaced. Past roughly half, another repair is usually the wrong call and this is the number that proves it. |
| Parts fitted over its life | Part number, description, date, quantity, cost and expected life | A parts history is also a fault history. It says what actually fails on this asset rather than what somebody remembers failing. |
| Times fitted | How many times that part has gone into this asset | The quiet early warning in the whole file. Three fittings inside a five year life is pointing at something other than the part. |
| Downtime hours | How long the asset was unavailable, in total | What converts a maintenance figure into an operational one, and usually the only column a production or clinical reader cares about. |
| What we have learned | Recurring faults, root cause, intervals changed, spares to hold | The section that survives staff turnover. Everything here is knowledge that otherwise leaves the site in somebody's head. |
Two columns in this file do almost all of the work, and both are routinely left empty because neither is needed to close a job. The first is current replacement cost. Without it the log is a record of money spent, which nobody can act on; with it, the same figure becomes a ratio against what a new asset would cost, and a ratio can be argued in a budget meeting. The second is times fitted. A parts list tells you what was replaced, and a times-fitted count tells you what keeps being replaced, which is a completely different piece of information. A run capacitor with a five year expected life that has gone in three times is not a run of bad capacitors. It is a sign of something upstream, and the only reason nobody investigates it is that the three fittings sit in three separate job records that nobody puts side by side.
B. What it looks like filled in
The lifetime position on one air handling unit, eight years in. Nothing here is a failure, and the last two lines are a capital conversation.
| Line | Value |
|---|---|
| Jobs on this asset | 22 |
| Preventive against reactive | 14 and 6 |
| Reactive share | 27% |
| Lifetime maintenance spend | 7,420 |
| Current replacement cost | 18,500 |
| Lifetime spend against replacement | 40% |
Forty percent is the number to sit with, because it is not yet a problem and it is close enough to become one. The working rule in the file is that once lifetime spend passes roughly half of replacement cost, the next repair is usually the wrong decision. This unit is eight years into service at forty percent, which means the decision is still open and will not be open for long. Nothing in that sentence can be said without a replacement cost recorded against the asset, which is exactly why that field matters more than it looks. The reactive share is the other half of the picture. Six unplanned jobs out of twenty-two is not alarming on its own, but read next to the parts register it might be: if the same capacitor accounts for several of them, the asset does not have six separate problems, it has one that nobody has traced.
Word for a version you want to adapt to unusual equipment, Excel for the one that calculates reactive share, lifetime spend and the ratio against replacement cost, with an Asset Register tab holding one row per asset, and PDF for the copy that goes in the plant room. One file per asset. Free, and yours to rebrand.
How do you keep a maintenance log?
Set the asset up once, then add a line per visit. The value is in the run, and the two fields people skip are the two that produce the answer. Six steps.
Set the asset up, including what it would cost to replace
Asset ID, description, location, criticality and install date, then current replacement cost. That last field is the one the whole document resolves to, and it is the one most often left blank because no job requires it.
Log every job on it, whatever kind it was
One row per visit with date, type, description, hours, parts, cost and who attended. Planned and unplanned go in the same register, because the ratio between them is the point.
Type each job honestly
Preventive, reactive, corrective, inspection or modification. A corrective job raised off an inspection is a different signal from a callout at two in the morning, and collapsing them loses that.
Record every part with its expected life
Part number, description, date fitted, quantity, cost and expected life. Then let the times-fitted count build itself, because that count is the earliest warning the file produces.
Read the lifetime position rather than the last job
Reactive share, lifetime hours, total spend and spend against replacement cost. Any single visit tells you almost nothing; the ratio across all of them tells you whether to keep going.
Write down what you have learned about the asset
Recurring faults, root cause if one was found, intervals you changed, spares worth holding and a repair-or-replace position. This is the section that stops the knowledge leaving with the person.
Repairing again versus replacing
The decision this log exists to settle, with the arguments each side actually uses. Only one column can be filled in from evidence.
| Aspect | Repair it again | Replace it |
|---|---|---|
| What it usually rests on | The quote in front of you | A ratio taken from the whole history |
| What the log contributes | Lifetime spend so far | Spend as a share of replacement |
| The signal that it is wrong | Spend past half of replacement | A low ratio on a young asset |
| What the parts register adds | A part fitted repeatedly | A fault traced and then designed out |
| How downtime enters it | Each outage priced separately | Total hours unavailable, together |
| Cost of deciding badly | A rebuilt asset that fails again | Capital spent on a sound machine |
The repair case is always easier to make, because the number in front of you is smaller. A four hundred repair beats an eighteen thousand replacement in every conversation that only looks at today, which is most conversations. What the log changes is the frame: the same repair read against eight years of accumulated spend is not four hundred, it is the line that takes an asset past half of what a new one costs. Neither answer is automatically right, and an asset at forty percent with a low reactive share is usually worth keeping. The point is that the argument becomes evidential rather than a contest between whoever last saw the invoice and whoever last attended the failure.
When the template starts to feel limiting
The file is built for one asset, kept over years. Four things start to hurt as soon as that is not the shape of the problem.
One file per asset, and hundreds of assets
The structure that makes a single asset legible makes an estate unreadable. Asking which assets are past forty percent means opening every file.
The times-fitted count depends on discipline
It only works if every part is logged with its number. One technician writing capacitor instead of the part number quietly breaks the count for that asset.
Replacement cost goes stale
The ratio is only as good as the denominator, and a replacement cost entered four years ago understates itself every year nobody revisits it.
The log and the work order are separate records
Jobs are closed somewhere else and retyped here, so the log is always slightly behind and occasionally wrong about what was actually done.
What running this in Facilio looks like
The history does not change. What changes is that it accumulates by itself, against the asset, instead of depending on somebody keeping a file up to date.
Asset Intelligence
Lifetime cost builds itself
Every job, part and hour attaches to the asset as it is closed, so spend against replacement is current rather than a figure somebody totalled at budget time.
Ops Performance Intelligence
A rising reactive share surfaces
Because the ratio is held per asset across the estate, a machine drifting from planned to reactive appears as an exception instead of waiting to be noticed.
Work Order Intelligence
The job is the log entry
What the technician closes is the record, so nothing is retyped and the history cannot quietly disagree with what was actually done.
Audit Report Intelligence
Repeat parts are matched across assets
The same part failing on several units reads as a pattern rather than as one line in one spreadsheet that only one person has ever opened.
Hallucination-free by design. Atom AI answers from the records in your tenant rather than generating plausible text, so an empty field reads as empty rather than filled in for you.
Frequently asked questions
What is a maintenance log?
A maintenance log is the complete service history of a single asset. Every job carried out on it goes into one register, whether it was planned, reactive, corrective, an inspection or a modification, along with the hours, the parts fitted and what each job cost.
The point of holding it all in one place is the ratios it produces: what share of attention has been unplanned, and how total lifetime spend compares with what the asset would cost to replace today.
What is the difference between a maintenance log and a preventive maintenance log?
This log holds every job on one asset and is concerned with cost and history over the life of the machine. A preventive maintenance log is concerned with scheduled work and whether it happened when it should have, measuring each visit against the date it was due.
They answer different questions. This one asks whether the asset is still worth keeping. The PM log asks whether the program is actually being run to interval.
When does a maintenance log say it is time to replace an asset?
The working rule in the file is that once lifetime maintenance spend passes roughly half of current replacement cost, the next repair is usually the wrong decision. It is a rule of thumb rather than a threshold, and it is meant to trigger a conversation rather than settle one.
Read it alongside the reactive share and the remaining expected life. A sound asset at forty percent with mostly planned attention is usually worth keeping; the same forty percent accumulated through unplanned failures in two years is not.
Why does the times-fitted count matter so much?
Because it converts a parts list into a fault pattern. Any one replacement looks like normal wear. The same part going into the same asset three times inside its expected life is telling you something about the asset rather than about the part.
It is the earliest warning the document produces, and it is almost always invisible in practice, because those three fittings sit in three separate job records that nobody reads together.
Should planned and reactive work go in the same log?
Yes, and keeping them apart is the most common way these logs lose their value. The reactive share of an asset only exists if both kinds of work are counted in the same register.
That share is the single most useful early indicator in the file. An asset whose attention is drifting from planned to unplanned is either on the wrong interval or has a fault nobody has traced, and neither is visible if the two kinds of job are filed separately.
Can one log cover a whole building?
It can be made to, and it answers a different question badly. This file is built around one asset, its replacement cost and its parts history, none of which mean anything aggregated across a building.
For a building you want the work sorted by building element rather than by machine, which is what a building maintenance log does. Use this one per asset and that one per building.
How far back should a log go?
Ideally to installation, because the ratio against replacement cost assumes lifetime spend. In practice most logs start when somebody decides to keep one, which is fine as long as the start point is recorded.
A partial history still works for reactive share, recurring faults and times fitted. It only understates the spend ratio, and understating it is the safe direction to be wrong in.
Does this replace a CMMS?
No. It is the record a CMMS would keep for you, kept by hand, which is worth doing when you have a small number of critical assets and no system holding their history.
It stops being reasonable at scale. Once you are asking which assets across a site are past a spend threshold, or which part is failing on more than one machine, you are asking questions a folder of spreadsheets cannot answer.
In one paragraph
A maintenance log is one asset and its whole service history in a single register, planned and unplanned together. Record current replacement cost when you set the asset up, because every useful figure in the file is a ratio against it. Log every job with its parts and their expected life, and let the times-fitted count build. Then read the lifetime position rather than the last invoice: spend against replacement, and the share of attention that has been unplanned.
The log is the floor, not the ceiling
Keep one per critical asset, record the replacement cost, and log the part numbers properly. Once you are comparing assets against each other, or chasing a part that fails on more than one machine, the spreadsheet has done its job.
