What Is Downtime?

Downtime is any period when an asset or system is unavailable for use - because it has failed, because it is being serviced, or because something outside it (power, parts, people, permission) is missing. It is the mirror image of asset uptime: every hour an asset was supposed to be working but was not. The word covers both a factory line standing still and a cordless drill sitting in a repair shop; the scale differs, the logic does not.

The word also carries an everyday “rest” meaning - downtime as a break between shifts. That sense is not what this page is about. Here, downtime is a measurable quantity attached to a specific asset over a stated window, and the whole point of naming it is to be able to count it, cost it and cut it.

This guide covers how downtime differs from idle time and outages, the types and causes worth separating, the arithmetic for turning stoppages into a percentage, how to price an hour of it for your own business, what a downtime log should record, and the levers that actually reduce it.

What you will learn

• Downtime vs idle time, standby and outage
• Planned vs unplanned downtime
• Types of downtime
• What causes downtime
• How to calculate downtime
• What downtime costs, and how to price your own hour
• Downtime tracking: what to log and why
• How to reduce downtime
• Downtime in IT vs downtime for equipment
• Downtime in practice
• FAQ

Downtime vs idle time, standby and outage

Several words get used for “the thing was not working”, and each points at a different problem:

The distinction decides which metric moves. Downtime pulls down availability; idle time pulls down utilisation. A generator that sat unused for three weeks because no site needed it has near-perfect availability and terrible utilisation - and buying a spare generator would be exactly the wrong response. A generator that sat unused because its starter failed is the opposite case. A log that records both as “not working” cannot tell you which one you have, so the team ends up buying equipment when it should be fixing a schedule, or vice versa.

Standby is worth naming separately because it looks like waste on a utilisation report and is often the correct answer for critical kit: a spare pump, a loaner laptop, a backup generator exists precisely to be idle until the day it is not.

Planned vs unplanned downtime

The most useful split is not what caused the downtime but whether anyone chose it. Planned downtime is scheduled - servicing, inspections, calibration, upgrades, cleaning - and the timing is picked to hurt least. Unplanned downtime is the asset deciding for you, usually mid-use, which is why an hour of it costs several times an hour of the planned kind: the work in progress stops, someone scrambles to diagnose, parts get ordered at speed, and commitments slip.

The relationship between the two is the core trade of maintenance, covered in more depth under planned vs unplanned maintenance: accepting small, scheduled unavailability to avoid large, random unavailability. A team whose planned downtime is rising while unplanned downtime falls is not getting worse - it is winning, and the headline “total hours down” figure will hide that unless you split it.

Types of downtime

The planned/unplanned binary is a good start and a poor finish, because it lumps together stoppages with completely different fixes. A taxonomy that survives contact with a small business looks like this:

• Planned - servicing, inspection, calibration, deep cleaning, software updates, scheduled part replacement. Chosen, dated, and cheap if it stays that way.
• Unplanned (failure or damage) - the asset broke, was dropped, or arrived damaged. The dramatic category, and usually not the biggest one.
• Administrative - the asset is broken and everyone knows it, but the repair is waiting for an approval, a quote, a decision, or a purchase order. Nothing is being repaired; a form is being routed.
• Logistical or supply - waiting for a spare part, a supplier slot, an engineer’s next available visit, or a courier. The repair is understood; the input has not arrived.
• Environmental or external - power cut, flood, weather, site closed, network down, road blocked. Outside your control, but not outside your planning.

In many small businesses the administrative and logistical buckets combined are larger than the failure bucket. A £40 belt that takes ten days to arrive costs more than the failure that snapped it, and an approval sitting in someone’s inbox for a week is pure, avoidable downtime. These buckets are invisible unless the log has a reason code for them - which is exactly why reason codes matter more than most teams expect.

What causes downtime

Behind the categories sit a fairly short list of recurring causes:

• Deferred or skipped preventive maintenance. The service that was postponed twice becomes the failure that stops the job. Preventive maintenance exists to move that stoppage into a slot you chose.
• Ageing assets kept past their useful life. Failure rate climbs at the end of an asset’s life, and the repairs get slower as parts get scarcer. Tracking useful life is what turns “it broke again” into a retirement decision.
• No spare on hand for a cheap, critical part. Filters, belts, hoses, chargers, batteries - low-value items whose absence stops high-value work. See spare parts management.
• Operator error and unfamiliar users. Shared kit passed between people who were never shown how it works fails more often, and fails in ways nobody diagnoses quickly.
• Damage in transit or on site. Equipment that moves between vans, sites and stores accumulates knocks that never get reported.
• Nobody knew it was faulty. The single most common cause in small teams: the last user noticed the fault, did not report it, and the next person discovered it at the worst possible moment.
• Approval and budget bottlenecks. The repair is agreed in principle and stalled in practice while a number gets signed off.

The pattern underneath is worth stating plainly: most downtime is not the failure itself, it is the queue in front of the repair. The hours between “it broke” and “someone started fixing it” are usually longer than the fix, and they are the cheapest hours to remove.

How to calculate downtime

The arithmetic is simple, and the definitions are where teams go wrong.

Downtime hours = expected available hours minus actual available hours, over a stated window.

Downtime rate = downtime hours ÷ scheduled hours × 100.

A worked example: a machine is scheduled for 160 hours in a month. Across the month it loses 12 hours to two stoppages. Downtime rate is 12 ÷ 160 = 7.5%, so availability is 92.5%, and the plain-language version is “we lost a day and a half of capacity”.

Two derived metrics follow from the same log:

• MTTR (mean time to repair) = total downtime ÷ number of incidents. In the example above, 12 hours across 2 incidents gives an MTTR of 6 hours.
• MTBF (mean time between failures) = total run time ÷ number of failures, and the two combine into availability = MTBF ÷ (MTBF + MTTR).

The one thing that breaks every comparison is the denominator. The same asset measured against calendar hours (720 in a 30-day month) rather than scheduled hours (160) turns 12 lost hours into 1.7% instead of 7.5%. Neither is wrong; quoting one without saying which is. Pick a denominator, write it down next to the number, and keep it stable so the trend means something. The asset uptime page works through the mirror-image formula and the “nines” convention in more detail.

What downtime costs, and how to price your own hour

The visible cost of downtime is the repair invoice, and it is rarely the largest line. Rather than borrowing a headline statistic from a report about somebody else’s factory, build your own cost per hour:

Cost per hour = idle labour + lost output + substitution + recovery drag

• Idle labour - loaded hourly cost × the number of people blocked. A three-person crew stood around a dead forklift is three salaries buying nothing.
• Lost billable or productive output - the jobs, units or hours that did not happen and cannot be reclaimed.
• Substitution - hire charges for a replacement, a subcontractor called in, or the quiet damage of doing the job with the wrong tool.
• Recovery drag - the catch-up after the asset is back: overtime, rescheduled customers, the backlog that took a fortnight to clear.

Add the things you cannot invoice but do pay for: missed slots, the customer who remembers the delay longer than you do, and the compounding effect on maintenance backlog when everything shifts right.

The small-business framing matters here, because most downtime writing assumes a production line. A single broken laptop does not stop a factory - it puts one person at part capacity for one to three days, and if that person is billable, the number is not small. The sum of many minor stoppages usually beats the one dramatic outage everyone still talks about, precisely because the small ones are never counted.

The figure only needs to be roughly right. Its job is not accounting; its job is to answer one question - is a spare, a service plan, or a faster repair route worth buying? If an hour of downtime costs £180 and a shelf spare costs £60, the decision is already made.

Downtime tracking: what to log and why

You cannot reduce a number nobody records, and downtime never records itself. A workable log captures, for each stoppage:

• Asset ID - which specific item, not which model. See asset ID.
• Start time and end time - duration is derived, never typed.
• Reason code - the field that turns a pile of hours into a decision.
• Who reported it - so the reporting habit is visible and can be encouraged.
• What fixed it - the note that saves the next person an hour of diagnosis.
• Cost of parts and labour - feeding both the repair-versus-replace call and total cost of ownership.

Reason-code discipline is what makes the log worth keeping. Use a short standard list - failure, planned service, awaiting part, awaiting approval, awaiting technician, damage, external - and cap it at ten to twenty codes. Resist adding an “Other” bucket: it silently eats the data, and within three months it will be your largest category and your least useful one.

Two rules decide whether logging survives contact with reality. First, it must take seconds, not minutes - a person holding a broken tool will not go and find a form, so the report has to be reachable from the item itself. Second, it must be non-punitive. The moment reporting a fault feels like admitting one, reports stop and your downtime figure improves for entirely the wrong reason.

On tooling, the honest line: a shared spreadsheet is a legitimate start, and it works right up until you are spending your time compiling instead of acting. When “which assets are down right now?” takes more than a glance, or when repair history lives in three people’s memories, an equipment log tied to the asset record earns its place.

How to reduce downtime

Roughly in order of cheapness:

1. Make reporting instant. A QR label on the item means the person holding it can raise the issue on the spot instead of finding a form or a manager. This removes the “nobody knew” hours, which are free to remove.
2. Cut approval latency. Pre-authorise repairs under a set value and name a single decision-maker above it. Costs nothing, removes days.
3. Convert unplanned to planned. Service on schedule rather than on failure. An inspection schedule turns a random outage into a chosen one.
4. Keep per-asset repair history. Repeat offenders only become visible when the history is per-asset rather than per-memory - and then they get fixed properly or retired.
5. Stock the two or three cheap parts that cause long waits. Not a stockroom, a shelf. Target the items with a long lead time and a short price tag.
6. Hold a spare or loaner for genuinely critical kit - and size that pool deliberately rather than by accident, using your cost-per-hour figure to justify it.
7. Work the maintenance backlog down so small faults do not mature into big ones.

Underneath all seven sit exactly two levers: reduce MTTR (fix faster) or increase MTBF (fail less). Small teams almost always get more from the first, because the biggest slice of their MTTR is waiting - for a report, a decision, or a part - and waiting is cheaper to fix than reliability.

Downtime in IT vs downtime for equipment

Half the people searching for this term mean a service, not a machine. In IT, downtime usually means a system or service is unavailable, measured against 24/7 clock time and written into a service level agreement as “nines”: 99.9% permits roughly 8.8 hours of downtime a year, 99.99% under an hour. The denominator is the calendar, because the service is expected to be there at 3am.

For physical equipment, that convention misleads. A van that is unavailable at 3am on a Sunday has not failed anybody. The sensible denominator is scheduled hours, and the useful unit is hours per period rather than an extra decimal place - “we lost 12 hours this month” tells a team more than “97.9%”.

Then there is the case most pages skip and small businesses actually live in: hardware downtime for a person. A dead laptop, a missing charger or a docking station that stopped working takes an employee to part capacity for days, and it rarely appears in any availability metric at all. For IT departments the practical fix is not a nines target - it is knowing who holds what, having one or two spares on the shelf, and making the swap a five-minute job rather than a procurement exercise.

Downtime in practice

The habit that makes everything else possible is marking the status change: the moment an asset goes out of service, its record says so, with a reason. In AMPthilly, setting an asset’s status to in repair and raising a service desk ticket gives the team a live view of what is down and why, and leaves a permanent repair history on the asset - which is how you later spot the machine that has quietly been down five times this year.

The reporting side matters just as much as the record. Because each asset can carry a printed QR label, the person who finds the fault can scan it with a normal phone camera, land on that asset’s profile in the browser, and report the issue with a photo and a category - damage, missing, needs maintenance, needs replacement - without hunting for anyone. The ticket then moves through a queue with statuses that map neatly onto downtime reason codes: in review, in progress, awaiting parts, resolved.

FAQ

What is the difference between planned and unplanned downtime?

Planned downtime is scheduled in advance - servicing, upgrades, inspections - so work can be arranged around it and the asset comes back in a known state. Unplanned downtime arrives without warning, at whatever moment the asset happens to fail, which is usually mid-use. The same hour of unavailability costs far more unplanned, because it adds scrambling, waiting for parts, and disrupted commitments on top of the lost use.

What is the difference between downtime and idle time?

Downtime means the asset cannot be used: it has failed, it is being serviced, or it is missing a part. Idle time means the asset is perfectly capable but has no work, no operator or no material. The distinction matters because it decides which number moves - downtime hits availability and points at maintenance, while idle time hits utilisation and points at scheduling or demand. Teams that log both as one bucket of “not working” end up chasing the wrong fix.

How do you calculate downtime as a percentage?

Downtime rate = downtime hours divided by scheduled hours, times 100. A machine scheduled for 160 hours in a month that lost 12 hours to stoppages was down 12 / 160 = 7.5%, giving 92.5% availability. Always state the denominator: the same asset measured against calendar hours instead of scheduled hours produces a completely different percentage, which is why two teams quoting downtime figures often are not comparing the same thing.

How much does an hour of downtime cost a small business?

There is no universal figure, so price your own: idle labour (loaded hourly cost times the number of people blocked) plus lost billable or productive output, plus substitution cost such as a hire or doing the job with the wrong tool, plus the catch-up hours after the asset is back. The number only has to be roughly right - its job is to tell you whether a spare, a service plan or a faster repair route is worth buying.

How is downtime measured?

At its simplest: the hours an asset was unavailable during the period it was expected to be available. Teams that want more insight split it by cause - failure, maintenance, waiting for parts, waiting for someone to fix it - because the split tells you what to change. The mirror metric is uptime or availability, the percentage of expected hours the asset was actually usable.

Does maintenance count as downtime?

Yes - if the asset is unavailable, it is down, whatever the reason. The useful distinction is that maintenance downtime is a choice about timing. A service slotted into a quiet day costs little; the identical service forced by a breakdown during a busy week costs a great deal. Counting planned downtime honestly is what stops it drifting into evenings nobody scheduled.

Tools that make this easier

AMPthilly keeps the downtime record where it is actually useful - on the asset itself. Each item has a status (in use, in storage, in repair, retired), so “what is down right now?” is a filter rather than a phone round. Issues are reported as service desk tickets tied to the asset, with a category, photos, comment threads and attached repair invoices, and they move through a queue - in review, in progress, awaiting parts, resolved - that doubles as your reason codes. Print a QR label for each asset and anyone can scan it with a phone camera, open the profile in the browser and report a fault in seconds, with no app to install. The full audit history of status changes, checkouts and returns stays on the record permanently, so the per-asset downtime story is already written when you come to count it. The free plan covers 3 users and 25 assets with no card required.

The takeaway

Downtime is any time an asset was expected to be available and was not - and the single most useful thing you can do with it is stop treating it as one number. Separate it from idle time so you fix the right problem, split it by reason code so the administrative and waiting-for-parts hours become visible, calculate it against a denominator you state out loud, and price an hour of it so you know what a spare is worth. Then remove the queue in front of the repair: instant reporting, fast approvals, a shelf with the cheap critical parts on it. For most small teams that queue, not the failure, is where the hours actually go.

Related terms

• Asset Uptime - the availability percentage downtime subtracts from
• Planned vs Unplanned Maintenance - the trade-off that determines which kind of downtime you get
• Maintenance Backlog - the queue of outstanding work that feeds future downtime
• CMMS - the software category focused on scheduling work to minimise downtime
• Service Level Agreement - the formal availability commitment downtime is measured against