Maintenance and CMMS — in the system that already counts your production

Two interval models — calendar and production count

A preventive maintenance schedule targets one piece of equipment and fires on one of two bases:

• Time-based — every N calendar days from the last execution.
• Usage-based — every N units produced on that equipment since the last execution.

The usage basis is production output recorded against the equipment, not a runtime-hours meter: Qontiv counts the units the line actually made rather than reading an hour meter or an odometer, because the production count is data the MES already owns. A schedule also carries the priority, assignee, estimated duration, and task instructions that every work order it generates inherits, and can be deactivated without being deleted.

The generator, and why it does not spam your queue

A worker sweeps every tenant hourly — configurable, and it also runs once at startup rather than waiting for the first tick. Due schedules produce a work order codedPM-000001 upward, typed Preventive, status Open, named for the schedule and the equipment, with the schedule's priority, assignee, and task instructions carried onto it.

The part that matters operationally: no second work order is created while one is still open. Before generating, the worker checks whether that schedule already has an Open or InProgress work order and skips it if so. A PM that nobody closed for three weeks produces one work order, not twenty-one. Completion is what advances the schedule — closing the work order stamps the schedule's last-executed date and recomputes the next due date from the completion date, so a PM done late does not immediately come due again.

Work orders technicians actually execute

Four statuses — Open, In Progress, Completed, Cancelled. Three types — Preventive, Reactive, and Condition-Based. Four priorities — Low, Medium, High, Critical. Starting a work order requires it to be Open; completing one requires it to be In Progress. Completion records the resolution and, optionally, the actual duration in minutes.

Checklists are per work order: a sequenced list of items, each with its own completed flag, completion timestamp, and the name of who ticked it. A schedule contributes its free-text task instructions to the work order; the item-by-item checklist is built on the work order itself, which is where a technician adding a step they found necessary belongs.

Role split, enforced on every mutation: maintenance technicians create, update, start, and complete work orders and add or tick off checklist items. Authoring PM schedules and deleting records is restricted to Admin, Platform Admin, Supervisor, and Maintenance Manager. A technician runs the work; they do not rewrite the maintenance program.

Reactive work and the breakdown record

Breakdown work is recorded as a Reactive work order against the equipment, which is what makes MTTR computable. Be clear on the boundary: Qontiv does not raise a corrective work order automatically from a downtime event. A supervisor or technician creates the reactive work order, and the two records are correlated by equipment and time window inside the reliability report rather than by a link the operator has to remember to set. The Condition-Based type exists as a classification you can select; no condition-monitoring trigger creates one for you.

MTBF and MTTR — with the formula printed

IATF 16949 §8.5.1.5 names MTBF and MTTR as maintenance objectives by name, so here is exactly how Qontiv computes them, per piece of equipment, over a window that defaults to the trailing six months:

• Operating hours = total hours in the window − recorded downtime hours.
• MTBF = operating hours ÷ number of downtime events in the window.
• MTTR = sum of recorded repair minutes ÷ 60 ÷ number of completed reactive work orders.

Both are rounded to two decimals and both return null rather than a misleading zero when there is nothing to divide. Three honest caveats, because a reliability engineer will find them anyway: every recorded downtime event counts in the MTBF denominator, so how you scope your downtime reasons determines whether you are measuring breakdowns or all stoppages; MTTR is computed from the actual duration technicians enter at completion, which is an optional field, so it reflects recorded repair time rather than automatically measured repair time; and the report is driven off the downtime set, so equipment with no downtime events in the window returns no row at all.

MaintainX linkage

If your technicians already live in MaintainX, Qontiv ingests from it. Assets map to Qontiv equipment and MaintainX work orders map to Qontiv maintenance work orders, keyed by a stored mapping record with deterministic local codes so the same remote object always resolves to the same Qontiv row. The webhook receiver verifies an HMAC-SHA256 signature before doing any work, and the API key and webhook secret are held encrypted and unwrapped through ASP.NET Core data protection. Handled events: work order created, updated, and completed; asset created, updated, and deleted. MaintainX has an on-hold state Qontiv does not, and it is translated to Open rather than silently dropped.

The conflict policy is the part worth reading twice: your Qontiv record wins.If the local record was edited after the last inbound sync and the incoming payload is older than that edit, Qontiv refuses to apply it, writes a failure record with reasonInbound/Conflict, and stores both payloads — the canonicalized local state and the remote one — on that record for diffing. The disagreement becomes something a person resolves, instead of the last webhook to arrive overwriting the shop floor's own record.

Echo suppression works two ways so an inbound update cannot bounce back out: a delivery older than the last one recorded is short-circuited before anything is applied, and the write that applies a remote change is marked as remote-applied in the same transaction, which stops it from producing an outbound row at all.

Scope, stated plainly: this is inbound today. Qontiv ingests MaintainX assets and work orders through the webhook receiver. It does not push changes back to MaintainX, does not poll MaintainX on a schedule, and does not import MaintainX PM schedules — MaintainX exposes no distinct PM endpoint for that. If you need write-back, say so in the demo rather than assuming it.

Why it matters that this is in the MES

One system — not a QMS bolted to an MES, and not a CMMS bolted to either. A usage-based PM fires on the production count the MES recorded, not a number re-keyed from a report. MTBF reads the downtime events operators entered against the same equipment the OEE engine is scoring. The equipment hierarchy the schedule targets is the ISA-95 hierarchy the rest of the plant is modeled on. A standalone CMMS cannot do any of that without an integration project, because it is not the system running production.

Regulatory mapping

Qontiv is designed for compatibility with these standards and produces the maintenance records an auditor asks for. Qontiv itself is not certified to any of them — your certification body audits you.

Scope — what this is not

• No spare-parts inventory. There is no parts catalog, no parts-on-work-order consumption, and no reservation. IATF 16949 §8.5.1.5 also asks for availability of replacement parts; that part of your TPM system stays where it is today.
• No labor-time or cost tracking. A work order carries an estimated and an actual duration — two numbers. There are no time entries, no per-technician clock-in, and no maintenance cost rollup.
• No offline mobile app. Work orders are executed in the browser on a floor device with a connection.
• Gauge calibration lives elsewhere. Calibration due-dates, certificates, and gauge status are part of MSA and gauge management, not the equipment maintenance module. They are deliberately separate records because a gauge out of calibration invalidates measurements, which is a different consequence from a machine needing a PM.

Availability

Maintenance management — PM and corrective schedules, work orders, MTBF and MTTR — is included in Professional, and the CMMS linkage falls under the same entitlement. See pricing for what each tier includes, orrequest a demo to walk your own PM program through it.