Maintenance and Downtime Tracking in Odoo 20

Every manufacturer knows the cost of a stopped machine; far fewer can say, with numbers, how much production time they lost last month, to which machines, and for how long. The Maintenance app in Odoo exists to close that gap. It keeps a record for every piece of equipment and every work center, routes maintenance requests — corrective and preventive — through a tracked workflow, and computes reliability statistics automatically from the history those requests create. Downtime tracking is not a separate module or report you switch on: it emerges from recording each stoppage as a request with a duration, on equipment whose failure statistics update themselves. Odoo 20 keeps that model and improves the planning side, adding dedicated Gantt views for maintenance requests and letting each maintenance team customize its own stages. Here is how the pieces fit together.

Equipment records: the foundation

Everything in the Maintenance app hangs off the equipment record. Each record identifies the asset — name, category, model, serial number, vendor and vendor reference, purchase cost, and warranty expiration date — and places it in the business: the company that owns it, the employee, department, or other party that uses it, its location, and, for production assets, the work center it belongs to. A maintenance team and a default technician are assigned on the record, so a new request knows where to go before anyone triages it.

Two dates on the record matter more than the rest. The effective date records when the equipment was first put into use, and the record's Maintenance tab holds the reliability metrics described below, all of which are computed from the equipment's own maintenance history.

Maintenance requests: corrective and preventive

A maintenance request is the unit of work. Requests are created in the Maintenance app, but they do not have to start there: production staff can trigger a maintenance request directly from the work center control panel in Manufacturing, which is how a breakdown on the floor becomes a tracked record instead of a shout across the plant.

Every request is for either a piece of equipment or a work center, and is one of two types:

Corrective — fix something that is broken or otherwise unusable. Corrective requests are the raw material for failure statistics: each one represents a failure event.
Preventive — scheduled work intended to stop failures from happening: inspections, lubrication, part replacement on a calendar or usage cycle. Preventive requests can be set to recur, and each piece of equipment carries a preventive maintenance frequency from which the next preventive maintenance date is calculated.

The request form links the work to its context. If the problem arose during production, the request can reference the manufacturing order — and, within it, the specific work order — so the stoppage is tied to the job it interrupted. The form also carries the responsible maintenance team and technician, a scheduled date for when the work should happen, a priority from zero to three stars (higher priorities sort to the top of the board), instructions for the technician — as text, an uploaded PDF, or a Google Slide link — and, if the Custom Maintenance Worksheets setting is enabled, a worksheet template to be filled out during the job.

Requests move through stages on a Kanban board by drag-and-drop: a new request lands in New Request, moves to In Progress while the work is done, and ends in Repaired — or in Scrap when the equipment cannot be repaired and must be retired. Requests can also be planned on the maintenance calendar, so scheduled work is visible alongside everything else the team owes.

Downtime tracking: duration, blocking, and repair time

Downtime becomes measurable because three elements of the request capture it:

Duration. Each request records how long the maintenance took, entered in hours and minutes. Aggregated over a period, durations by equipment, team, or type are your downtime ledger — planned (preventive) versus unplanned (corrective) separated by the request type.
Block Workcenter. When a request is for a work center, a Block Workcenter option prevents work orders or other maintenance from being scheduled at that work center while the request is being processed. Planned downtime stops being invisible: the production schedule itself respects the stoppage instead of double-booking a machine that is in pieces.
Mean time to repair (MTTR). Odoo defines MTTR in terms of downtime — the total repair time divided by the number of repairs — and computes it for each piece of equipment automatically as requests are completed. A rising MTTR says repairs are getting slower or harder; a falling one says the team, the spares, or the procedures are improving.

Access control supports the workflow without bottlenecks: users with Equipment Manager rights can raise requests on any equipment, while other users can be added as followers on individual equipment records, which lets them create requests for those assets without broader access.

The reliability numbers: MTBF and the next failure

The Maintenance tab on each equipment record shows five metrics, four of them computed automatically from completed corrective maintenance:

Expected Mean Time Between Failure — the one editable field: how many days you expect between failures, used as the planning baseline before real history exists.
Mean Time Between Failure (MTBF) — the actual average days between reported failures, computed from completed corrective maintenances, starting from the equipment's effective date for the first failure.
Latest Failure — the date of the most recent reported failure.
Estimated Next Failure — computed as Latest Failure Date + MTBF, giving you a forecast date to plan inspections or spares around.
Mean Time To Repair (MTTR) — the average time taken to repair the equipment once it fails, updated whenever a maintenance request for it is completed.

These are the numbers that let a maintenance programme improve deliberately. Compare MTBF against the expected value to find assets that fail more often than they should. Use the estimated next failure date to pull a preventive task forward instead of waiting for the breakdown. Watch MTTR by equipment to spot the machines whose repairs always turn into sagas — usually a spares, documentation, or training problem rather than a technician problem. Odoo's own positioning of the app makes the loop explicit: use the automatically computed statistics to fine-tune your preventive maintenance rules and reduce the risk of equipment failure.

What is new in Odoo 20

The Odoo 20 release notes give Maintenance a short but useful list:

Gantt views for maintenance requests. Equipment and work center requests now have dedicated Gantt views, so planned maintenance can be viewed on a timeline — and clashes with each other, or with heavy production periods, spotted before they happen. For downtime planning this is the headline change: scheduled stoppages become something you arrange on a calendar rather than discover in a list.
Stages per maintenance team. Maintenance stages can now be customized for each maintenance team, so a facilities team and a production-line team can run different workflows — different triage or approval steps — instead of sharing one compromise pipeline.
UX improvements. A round of interface refinements, including a new “Status” widget on maintenance records.

Two Manufacturing changes in the same release complete the picture. The work center overview now includes quick links to work orders and maintenance planning, tightening the jump between a production problem and the maintenance schedule. And it is now possible to process work orders in blocked work centers — a deliberate relaxation that lets supervisors keep non-dependent work moving when a work center is marked blocked, rather than having the block freeze everything attached to it.

Running the programme

The discipline that makes Odoo's maintenance data worth reading is simple: every stoppage becomes a request, raised when it happens, with the manufacturing order attached when production was interrupted, and closed with an honest duration when the machine is back. Skip the request and the downtime vanishes from the record while remaining very real on the floor. With that habit in place, Odoo 20 gives you the ledger (requests and durations), the forecast (MTBF and estimated next failure), the repair benchmark (MTTR), and — new in this version — the Gantt timeline and per-team workflows to plan the work properly. That is a complete downtime programme, built out of records your team was already supposed to be creating.