How due is worked out

A maintenance schedule says how often a service repeats. You will be able to add schedules, read the board, and understand why a service shows as due soon or overdue and which component caused it.

Before you start #

• Add the asset and its first meter readings. See assets-and-meters.
• Fleet writes need the dispatch_fleet license flag.

Steps #

1. Add a schedule with POST /fleet/assets/:id/pm. Send service (the name) and at least one interval above zero:
   • interval_distance, in the asset's unit
   • interval_days
   • interval_hours, up to two decimals The baseline starts as today and the asset's current readings.
2. Adjust the due-soon thresholds if the defaults suit you less. Send soon_distance, soon_days or soon_hours in the same call. The defaults are 500 miles, 30 days and 50 engine hours.
3. Choose how a completed service resets the schedule with reset_mode: actual (default) or fixed.
4. Read the board with GET /fleet/pm/board, worst first. Use GET /fleet/assets/:id/pm for one asset.
5. Switch a schedule off with PATCH /fleet/pm/:id and {"active": false}; it leaves the board and the reminder job but is kept, and {"active": true} brings it back. The board shows only assets in use by default. Add active=0 for retired assets or active=all for both, and schedules=off or schedules=all to see switched-off schedules.
6. When the service is done, call POST /fleet/pm/:id/complete. Send serviced_on (default today) and, if you have them, distance and hours. A reading sent here joins the meter log.

How a schedule is judged #

Each interval is a component with its own due point: baseline plus interval.

• Distance and hours are overdue once the reading reaches the due point, and due soon when what is left falls within the threshold.
• Days are due soon inside the threshold and overdue once the due date has passed. A service due today shows as due soon.
• The worst component wins. A schedule with several intervals takes the worst status among them, which is whichever comes first. The board names that component, for example "Oil service is overdue because of distance". On a tie, distance comes before days, and days before hours.

Actual or fixed reset #

With actual, the next baseline is the real reading at the service, so a late service pushes the next one later. With fixed, the cadence stays on its original rhythm. The next baseline advances by whole intervals from the old baseline, so an early or late service leaves the schedule's rhythm alone.

Projections, stale meters and missing meters #

• Projection: Pop Dispatch divides what is left by the average daily use over the last 90 days. It needs at least two readings in that window that span 14 days or more. Until then the board says there are too few readings for a projection.
• Stale meter: a meter with no reading in 30 days carries a warning on its row, and the nightly job writes a stale-meter reminder for the asset.
• Missing meter: a component that needs a meter the asset has no reading for appears in the board's missing list, named, and never disappears from view. Add a reading to bring it into the judgment.

If something goes wrong #

• validation_failed (422) with fields: ["interval"]: give at least one interval above zero.
• validation_failed (422) with fields: ["service"]: name the service.
• validation_failed (422) with fields: ["reset_mode"]: use actual or fixed.
• not_found (404): no such asset or schedule.
• invalid_date (422): write serviced_on as YYYY-MM-DD.
• feature_not_licensed (403) or licence_read_only (403): see fleet-overview-and-setup.