Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Equipment maintenance scheduler series ~6 min read

An equipment maintenance scheduler on AWS for a few dollars a month

The service was due in March. March was the busiest month of the year, so it slipped to April, and April slipped to May because the part was on back order, and in June the bearing failed during a production run. Nobody made a bad decision at any point; there was simply no place where the accumulated slippage was visible. This post walks through a small system built around that.

a few men working on a project
Photo by Etienne Girardet on Unsplash

Key takeaways

  • Schedule on running hours where they exist, on calendar where they do not.
  • Deferral is normal and must be recorded with a reason and a name.
  • Statutory inspections are a separate track and cannot be deferred at all.
  • Over-maintenance is a real cost, and intervention itself causes failures.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: equipment usage tracked, jobs scheduled, deferrals recordedThree boxes across the top sit outside the AWS account. On the left, The machines, reporting hours, cycles, or nothing at all. In the middle, Schedules from the manufacturer and from statute. On the right, Whoever does the work, and whoever defers it. Each connects by an arrow to the AWS account container below. Readings flow down into the account. Intervals and rules feed in. A short list, and a debt, go back out. Inside the AWS account are three components in a row. On the left, the Usage tracker, counting hours since last service rather than months. In the middle, the Due list, showing what, when and how urgently. On the right, the Deferral record, capturing who, why and until when. A note at the bottom says the third box exists because the first two are the easy part.AWS ACCOUNTThe machineshours, cycles,or nothing at allSchedulesmanufacturer,and statutoryWhoever does the workand whoever defers itUsage trackerhours since last,not monthsDue listwhat, when,and how urgentlyDeferral recordwho, why,and until whenreadingsintervals andrulesa short list, anda debtThe third box exists because the first two are the easy part.
Fig 1. Three things outside the account, three pieces inside it. Most maintenance systems build the first two and treat the third as an edge case, which is backwards.
  • Compute
  • Database
  • Management
  • Analytics
  • People

Deferral is the design problem

Every maintenance system schedules jobs. The ones that fail in practice fail because reality intervenes: the machine is needed, the engineer is ill, the part has not arrived, the job is genuinely less urgent than the thing it would displace.

When there is no way to record that, the job simply stays overdue, the overdue list grows until it is meaningless, and everybody starts ignoring it. Making deferral a real action with a reason and a new date keeps the list short enough to be believed, and turns the accumulated slippage into something visible.

What runs (the inside)

  • The usage tracker. Records running hours or cycles and works out how much each machine has done since it was last serviced. Part 2.
  • The due list. A short, ordered list of what needs doing, with its urgency and its consequence. Part 2.
  • The deferral record. Who moved a job, why, until when, and what the cumulative picture looks like. Parts 3, 4 and 5.

One machine, end to end

One machine from service due through to a recorded deferralA horizontal row of five boxes joined by arrows. Serviced at four thousand two hundred hours, with a five hundred hour interval. Now at four thousand six hundred and forty hours, eighty-eight per cent through. Due: appears at ninety per cent. Deferred: two weeks, part on order. Visible as debt until it is done. A note says the fourth box is a legitimate decision, and the fifth is what stops it becoming three.ONE MACHINE, END TO ENDServiced at 4,200hinterval 500hNow at 4,640h88% throughDueappears at 90%Deferred+2 weeks, part on orderVisible as debtuntil it is doneThe fourth box is a legitimate decision. The fifth is what stops it becoming three.
Fig 2. The same system as one line. The deferral in the fourth box is fine; the mechanism in the fifth is what keeps it from repeating quietly.
  • Compute
  • Management
  • Analytics

In plain words

A machine was last serviced at four thousand two hundred running hours and the interval is five hundred hours. It has now done four hundred and forty since, which is eighty-eight per cent of the way. At ninety per cent it appears on the due list, which is early enough to arrange and late enough not to clutter.

The part needed is on back order, so the job is deferred by two weeks with that reason and the name of whoever decided. It stays on the list, marked deferred rather than overdue, and the reason is visible next to it.

If it is deferred again the system says so explicitly: second deferral, now at a hundred and twelve per cent of interval. A third deferral triggers a different conversation. Nothing is blocked, nothing is automated, and the accumulated position is impossible to lose track of.

Design rules that shaped every decision

  • Usage where it exists, calendar where it does not, and say which is being used.
  • Deferral is a recorded action with a reason, a name and a new date.
  • Statutory inspections are a separate track with no deferral action at all.
  • The due list is short. Anything longer than a day’s work is not a list, it is a backlog.
  • Never auto-close a job. A completed job is somebody saying they did it.
  • Record the parts needed with the job, because parts are why most deferrals happen.

Why this shape

Maintenance software is usually built around the work order and treats scheduling as arithmetic. That is the wrong emphasis for a small operation, where the arithmetic is trivial and the actual difficulty is that there are more jobs than hours and somebody has to choose.

So this design puts its weight on making that choice visible: what is due, what has been put off, how far past due things are, and which machine keeps appearing. The scheduling is the easy half and it is not where the failures come from.

The next four posts walk through each piece: how the interval gets decided, how a deferral gets recorded, which jobs cannot be deferred, and what the history tells you. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts