Maintenance items

What it is

A maintenance item is a scheduled task tracked against a single asset: an Annual Inspection, an ARC renewal, a 50-Hour check, an oil change. Each item records:

What the task is (name, description).
When it is next due (calendar date, or a value on the measure it counts).
Which measure a usage-based item counts against — flying hours, your engine meter, or landings.
Its current status, calculated from how close to due it is.
A completion history: who completed it, when, and at what value.

Items can be created by hand for a specific asset, or added from a maintenance template.

Who can use it

All members can see maintenance items on assets in their syndicate. The list and the item screen are read-only for them: the Add maintenance item buttons and Save Changes are not shown, and the fields cannot be edited. The New Maintenance Item screen is not shown to a member at all, including by direct link, so a create can never be started and then refused.
Admins can create, edit, and log completion. The server restricts logging a completion to syndicate admins, so a member who carried out a usage-based item themselves still asks an admin to record the completion.

Where to find it

Asset detail → Maintenance tile → Maintenance list.
Route: /syndicates/:syndicateId/assets/:assetId/maintenance.
A quick-stats card on the asset detail shows the next-due picture at a glance.
Tap an item to open its own screen. A deferral and a secondary calendar limit, where either applies, are shown there alongside Log Completion.

Fields / options

Field	Required	Notes
Name	Yes	Up to 100 characters. E.g. `100-Hour Check`.
Description	No	Up to 500 characters.
Interval type	Yes	Hours, Day, Month or Year in the create form. Existing items may use Cycles (see Maintenance intervals).
Counts against	When usage-based	The measure the interval is counted on: Flying hours, your meter’s own name plus “hours” (e.g. Tacho hours), or Landings for a cycles item. Only measures your syndicate records are offered. An admin can change it after creation, but the item has to be re-baselined at the same time (see Behaviour rules).
Interval value	Yes	Number in the chosen unit (e.g. `50` for hours, `1` for a yearly item). Calendar intervals must be whole numbers; hours may be fractional.
Last completed (date)	When calendar-based	Used to compute the next due date.
Last completed value	When usage-based	The value of the measure above at last completion.

Computed read-only fields:

Field	Meaning
Due at (date)	For calendar-based items: the last-completed date plus the interval, in the unit chosen — days, calendar months, or calendar years.
Due at value	For usage-based items: `last_completed_value + interval_value`, on the scale of the measure the item counts.
Status	One of OK, Approaching, Due Soon, Overdue, Completed. See Behaviour rules.

Secondary calendar limit

A usage-based item (hours or cycles) can also carry a calendar limit, so a check falls due at whichever comes first — for example, “every 50 hours or every 4 months”. A calendar-based item cannot carry one; it has only the one clock to run on.

Field	Notes
Also limited by a calendar interval	Switches the secondary limit on. Off by default.
Calendar interval	A whole number of days, months or years.

The two limits are judged separately and shown separately, each with its own status, so you can see which one is actually driving the check rather than only the worse of the two. Both reset together whenever the item is signed off. The secondary limit can be added when the item is created, or afterwards on the item’s own screen. The template setup sheet offers no control for it — but a template can carry one and set it for you, and Oil Change does: it comes with a four-month calendar limit alongside its hours interval, so an item created from that template arrives with both clocks already running.

Because both clocks restart from the same sign-off, a calendar limit set on the item’s own screen is refused if somebody else signs the check off while you are editing it. The limit you were entering counts from the completion that sign-off has just replaced, so recording it would file a date the work has already passed, and the check would read overdue on its calendar half from the day it was serviced. Nothing at all is saved in that case, not even the other fields on the form. Reopen the item and set the limit against the new cycle.

Signing the check off yourself from this screen, or deferring it, does not have that effect. Those changes are your own and the form keeps up with them, so a limit you set immediately afterwards is saved against the cycle you have just created.

The calendar limit is written before the rest of the form rather than alongside it, so there is one case where part of an edit lands and part does not: the limit is recorded and the remaining fields then fail to save. Syndik8 says which of the two happened, so the message never reports “nothing was saved” for a save that has already moved an airworthiness limit. Save again to apply the rest.

Deferral

An admin can move a check’s limits out, with a mandatory reason that is shown on the check to everyone who reads it. Each limit moves in its own units: a usage limit by a reading, a calendar limit by a date. A check running on two limits can have either moved or both — an oil change of “50 hours or 4 months” on an aircraft flying thirty hours a year always bites on the calendar half, so being able to move only the hours would be no help to it.

Syndik8 suggests no allowance. Each field opens on where that limit falls due today and the admin moves it, and a limit can only ever move outwards from the one the check was originally set to. Deferring moves the limit; it does not silence the warning or stop the asset grounding once the new limit passes. See Defer a maintenance limit.

Behaviour rules

Status calculation is automatic. It is derived from how much interval remains, not stored directly.
Each item is measured against its own basis. Two items on the same aircraft can count different measures and will come due independently — an oil change on engine hours, a 50-hour check on flying hours. The figures shown carry the measure’s name so the two are never confused.
Changing the measure re-baselines the item. A due-at value is an absolute reading on one measure’s scale, and it means nothing on another: a check due at 1300 on a Tacho meter is hundreds of hours ahead of the same aircraft’s accumulated flying time, and the reverse crossing would show the item overdue at once. So when an admin changes Counts against, the edit form asks for the reading the new measure showed at the last completion, and works the due-at value out again from that plus the interval. Until that reading is supplied the change cannot be saved, so an item can never be left judged against a threshold belonging to the measure it has just left. The interval value itself is unchanged: 50 hours is 50 hours on either basis. If the new measure has no reading of its own on the aircraft yet, the edit form also asks what it reads right now — the same figure the create form and the template sheet ask for — and refuses to save until that is given too, alongside the re-baselined Last Completed At.
The aircraft must already have a reading for the measure. An item counting something the aircraft has no figure for could never come due: there is nothing to compare it against, so it would read as healthy for ever. A new aircraft is in that state until somebody states a figure — flying hours and landings are counted up from a starting point, so logged flights say how much has been added and never what the total is. Every form that pins an item to a measure therefore asks what that measure reads on the aircraft now, inline, when it is missing, and will not save without it; the database refuses the item as well, so no other route in can skip it. The figure is recorded against the aircraft, and is a separate fact from the reading at last completion.
A new hours item opens on what the aircraft reads now. The create form’s Last Completed At field starts at the measure’s current reading rather than at zero, because an admin setting a check up today means “as of now” — the first cycle then falls due one interval ahead of the aircraft. Starting at zero files a 50-hour check on an aeroplane reading 1250 as due at 50, which is out of limits before it exists and grounds the aircraft that night. The field can still be typed over for work carried out a while ago, and it follows the measure: pick a different Counts against and it re-opens on that measure’s reading. Where the aircraft has no reading for the measure it opens empty instead, because a blank the admin must fill is honest and a zero is not.
Default thresholds (percentage-based):
- More than 20% remaining → OK
- 10–20% remaining → Approaching
- 0–10% remaining → Due Soon
- Past due → Overdue
Absolute threshold takes priority. Some items carry a warning threshold value (set automatically when the item is created from a template). When present, the status uses absolute remaining instead of percentage. The bands are tested in this order, most urgent first, and the first one that matches wins:
- Past its due reading or due date → Overdue
- Remaining ≤ warningThresholdValue → Due Soon
- Remaining ≤ warningThresholdValue × 2 → Approaching
- Anything else → OK
The threshold is read in the item’s own units: hours or landings for a usage item, days for a calendar one.
Overdue grounds the asset. An overdue maintenance item makes the asset not airworthy and prevents new bookings. See Airworthiness rules.
Admins are warned before that happens. Once an item enters Due Soon, its syndicate’s admins get a reminder once a week; once it is Overdue, they get one every day. These go to admins only, since only an admin can book the work in.
The whole syndicate is told when the asset grounds or comes back, whether the cause is an overdue item, a grounding squawk, or both. Every member gets an Asset grounded notice naming the reason, and an Asset restored notice once every cause has cleared. See Notification types.
Signing off offers to schedule the next occurrence. Completing an item works out its next due point and offers it to you, already filled in — accept it, change it, or switch the offer off. Switching it off leaves the item Completed and nothing scheduled, which is what completing an item always used to do. There is no separate setting to turn recurrence on first: any item with an interval is offered a next occurrence when it is signed off.
A calendar item keeps its anniversary. The next due date is its previous due date plus the interval, so an annual due on 15 March falls due on 15 March next year whether it was signed off on the 10th or the 20th. That is the date the aircraft’s paperwork carries and the one the workshop is booked against, and counting from the work instead would let it walk round the calendar a little further every year. Signing off early does not pull the anniversary forward either. With one exception: where the anniversary is already behind the work — a check signed off very late, or one that has never had a due date — the interval runs from the day the work was done instead, so a check just signed off can never be filed as already overdue.
A usage item counts from the reading. The next due value is the completion reading plus the interval: a 50-hour check flown to 160 next falls due at 210. There is no anniversary to hold, because the meter only goes up. Signing off late does not carry the overrun into the next cycle, and signing off early does not shorten it.
A secondary calendar limit, if the item has one, resets at the same time as the item’s own interval. Both clocks restart from the same sign-off, counting from the day the work was done, so “whichever comes first” starts counting again from scratch. See Secondary calendar limit.
A deferral is spent by the sign-off. Completing a deferred item clears every deferral on it, both limits included: the new cycle counts from the item’s own anniversary or completion reading, not from wherever a deferral had pushed the old limit.
The completion value is typed by hand. It is not read from the aircraft’s meters, so enter it on the scale of the measure the item counts. Syndik8 checks only that it is a number, is not negative, and is not below the previous completion value.
Every item is filed under the day the work was done. The Completed On date is what sets Last completed, so an annual signed off on the 15th and entered on the 20th reads as done on the 15th. Both kinds of item are asked for it, and on both the date cannot be earlier than the item’s previous completion; a usage item opens the field on today, a calendar item starts it empty. When the record itself was made is kept separately, so the two facts are not confused. The date matters on a usage item too, because it is what a secondary calendar limit counts from and what the sign-off carries into the tech log.
Only one sign-off per cycle can land. A sign-off answers the check as it stood when the form was opened, so if the check’s limit moves while the form is open — another admin signing the same work off, or a deferral being granted — the sign-off is refused with a message saying so, and nothing is recorded from it. Without that, one visit to the workshop could advance the check two cycles and leave two entries in the tech log for the same work. Signing the next cycle off later is unaffected: that form is opened against the new cycle.
Completion records include the completing user, the timestamp, the value at completion (for usage-based items), and optional notes. Each sign-off is also added to the asset’s maintenance history, which appears alongside its flights and squawks in the tech-log export.
The pre-booking maintenance check is computed locally. When a member opens the booking dialog, Syndik8 evaluates the asset’s open hours-based and calendar-based items — each against the measure it counts — using the synced readings and recent usage logs, in around 10 ms, entirely on the device with no server call. The amber/red warning surfaces whether the device is online or offline. Calendar items raise an amber warning when the booking ends within 7 days of due. Hours-based items use a projected-remaining estimate based on the member’s recent usage rate.