Downtime Event Data Model: The Fields Each Stop Record Needs

Key takeaways

• One stop, one row, with one start, one end and one reason.
• Timestamps come from the machine or gateway clock, not from the database.
• The OEE loss is fixed per reason code in setup. The operator never picks it.
• Starved and blocked are states, linked to the stop that caused them.
• Price every row, so the list can be sorted by money, not only by minutes.

Each stop on a line should land as one row with the same fields, whatever machine it came from and whoever logged it. Get those fields right once, and the Pareto, the OEE and the cost of each loss all come out of the same table.

Fabrico, OEE and light MES software with AI cameras, logs each stop automatically and asks the operator to confirm the reason in one tap. The record below is the vendor-neutral version. Use it to check any system, including a spreadsheet you build yourself.

What is a downtime event?

A downtime event is one unbroken period in which a machine did not produce, with one start time, one end time and one confirmed reason.

Very short stops need a rule of their own. No standard fixes the cutoff, so each plant sets one. A common rule flags any cycle that runs 1.5 to 2 times longer than the ideal cycle.

Stops under the plant's cutoff count as minor stops in Performance. They are counted and timed, but nobody asks the operator for a reason each time.

Which fields does each stop record need?

These 14 fields cover the stop, its cause, its context and its price.

Record the shift, not a named operator. A stop log is there to fix the process. It should never become a way to rank people.

How should reason codes link to OEE losses?

Each reason code belongs to exactly one OEE loss, and that link is set once in setup. If operators choose the loss themselves, the same jam lands in Availability on one shift and in Performance on the next.

• Keep the list short: 10 to 20 codes per line. More than 30 makes the operator's choice unreliable.
• Split the quality stop: a quality check that halts the line is Availability; the rejected units are Quality.
• Watch "Other": above 5% of stops, it signals missing categories, not lazy operators. Read the free text each month and promote clusters to codes.
• Test the list: three operators code the same five stops. Rewrite any pair of codes they disagree on.

Our guide to downtime reason code design goes deeper, and operator friendly reason codes shows how to keep the list usable on a tablet.

How do you record starved and blocked time?

A machine that waits for product is not broken. Give it the state "starved" or "blocked", and link the row to the stop that caused the wait.

OPC UA for Machinery draws the same line. Its state OutOfService means a technical reason inside the machine, such as a breakdown. NotExecuting means the machine is fine but waits, for an outside reason like starvation, a changeover or no order.

With the link in place, you can report two Availability figures for each machine: all causes, and its own causes only. Only the second is that machine's to fix.

Worked example: one hour of stops on a filler

Sample line (illustrative numbers, not a customer). A filler runs at 600 bottles a minute. The contribution margin is USD 0.12 a bottle (about EUR 0.11), so one lost minute at the filler costs USD 72 (about EUR 66). The plant's cutoff for minor stops is 30 seconds.

In one hour the filler lost 8 + 3 + 4 + 12 + 5 = 32 minutes, worth USD 2,304 (about EUR 2,120).

Of the 28 minutes that needed a reason, 23 have a specific one. The other 5 sit in "Other". Reason coverage = 23 / 28 = 82.1%.

Sorted by minutes, the capper jam looks like the biggest problem. Sorted by money, the changeover overrun comes first at USD 864. And the 3 starved minutes belong on the depalletiser's list, not the filler's.

Which mistakes break a downtime data model?

1. Database timestamps. Stamp each event with the machine or gateway clock at the moment it happens.
2. One row per shift. A daily total hides which stop cost the most.
3. The operator picks the OEE loss. Fix it per code in setup instead.
4. Fifty codes. A long list pushes everyone to "Other".
5. No edit history. Keep the first reason and every change, each with its time.
6. Starved time on the wrong machine. Link it to the stop that caused it.
7. Names in the report. Report by line and shift, never by person.

For the wider picture of how stops, counts and shifts fit together, see our OEE data model. For the short stops, read our guide to micro stops.

Where does Fabrico fit?

Fabrico is a computer vision enabled Manufacturing Performance Platform. OEE and light MES come first. Each stop becomes one record of this kind, without retyping.

• Automatic downtime logging from the machine signal, with start and end times.
• The operator confirms the reason in one tap, from a short list per line.
• A camera clip as evidence for a stop, where a camera watches the station.
• Every loss priced in money and ranked, so the costliest stop rises to the top.
• A work order to the right technician, with its cost, when the stop is a breakdown.

It is the OEE and downtime layer of a light MES, and it starts with a pilot on one line. There is no free plan and there are no tiers: each plant gets a quote.

Frequently asked questions

What fields should a downtime log have?

Start with the machine, the start and end time from its clock, the machine state and the reason code. Add the OEE loss it maps to, and whether it was planned. Add the order and SKU, the shift, the confirmation time, a camera clip where you have one, and the cost of the stop.

What is the difference between machine state and downtime reason?

The state is what the machine signal says: running, stopped on a fault, starved, blocked or off. The reason is why, such as a capper jam or a missing label reel. The machine can give the state on its own. The reason usually needs a person to confirm it.

How many downtime reason codes should a line have?

Aim for 10 to 20 codes per line, grouped under the big loss types. More than 30 makes the operator's choice unreliable, and the "Other" code starts to grow. Review the list every month in the first months, then whenever "Other" climbs again.

Should micro stops get a reason code?

Usually not one by one. Set a cutoff, often 1.5 to 2 times the ideal cycle, and count stops under it as minor stops in Performance. Look at them as a group by machine and SKU. Ask for a reason only for stops above the cutoff.

Can I build this downtime table in Excel?

You can build the table, but filling it is the hard part. Typed stop logs miss short stops and get rounded. Times typed after the shift do not match the machine. A spreadsheet works as a first model; the data needs to come from the machine signal.

See your stops as one clean table

Bring one line's current stop log. We will show the same stops as records with reasons, clips and costs.

Request a demo · Contact us