Troubleshoot wrong utilization or OEE

Symptom, cause and fix for numbers that do not match the floor.

Uptime is availability: running time over running plus stopped time. It is the number the interface has labeled OEE, and it is built from one thing, the running and stopped states a sensor reported. So a number that looks wrong is usually wrong about where a boundary fell, what the window covered, or what the sensor was doing at the time.

Every metric named on this page is defined in How each metric is calculated.

Start here: four checks

My numbers look wrong: the four branches, starting with the organization timezone.A decision tree headed My numbers do not match the floor, branching into four checks to work in order. Check 1, the organization timezone: does the Schedules panel name your plant's zone? Its blast radius is every number, on every machine, in every window. Check 2, the shift schedule: do the times and days match the floor's calendar? Its blast radius is every number scoped to a shift. Check 3, the window on screen: the shift, the date, the filters, and the Exclude switches. Its blast radius is every number on this screen. Check 4, this one machine: gray on its status bar, or thresholds set wrong. Its blast radius is one machine. A note across the bottom reads: widest blast radius first. A wrong timezone leaves every number looking plausible, which is why it is checked before anything else.

Check the organization timezone before anything else. It is the single setting that makes every number wrong at once, and nobody suspects it, because the numbers still look plausible. A plant in Detroit whose organization reads UTC sees whole shifts of production land in the wrong day.

Work the four in order. Each rules out a cause the ones after it cannot explain.

1. Timezone. Open Organization Settings from the gear at the top right of the header and read Schedule Timezone in the Schedules panel. It must name the plant's zone, not the head office's and not yours.
2. Shift schedule. In the same panel, read Work Schedule. The days on each shift matter as much as its times.
3. The window on screen. Read the shift and date selector, the department and tag filters, and the Exclude Unknown and Exclude None switches if you are on the Advanced Report.
4. This one machine. Read its status bar across the window in question. Gray is time the sensor said nothing; red is time it said the machine was stopped.

Then jump to your symptom.

Utilization too high

Uptime above what the floor believes is almost always stopped time being counted as running time.

1. Open the machine's calibration panel and read the short-stop control. With Treat short downtimes as uptime on, every stop under the cutoff becomes runtime. A 10-minute cutoff on a machine that stops six times a shift adds an hour of uptime nobody worked. See Handle short stops.
2. Read the stopping threshold. Set too low, the trace never falls below it, and a machine humming on standby reads as running. See Running when idle.
3. Check whether Exclude None is on. It removes a mandated lunch hour from the denominator as well as the numerator, which raises the percentage without anyone producing more. See The None severity.
4. Rule out the Uptime Filter. It drops runs shorter than a set number of seconds, so it pushes uptime down, never up. See Filter out short uptimes.

Convert short stops to uptime only when the pause is part of the cycle. Indexing and brief cooldowns qualify. A tool change does not: it is real stopped time, and converting it means the plant can never see what tool changes cost.

Utilization too low

A number below the floor's expectation is usually honest, and the fix is a schedule change rather than a settings change.

1. Compare Work Schedule to the hours the plant actually runs. A shift defined 6 AM to 6 PM on a plant that runs 7 AM to 3:30 PM adds three and a half hours of downtime to every machine, every day.
2. Check the days on each shift. A shift listing Saturday and Sunday on a plant that runs five days makes every weekend a full shift of downtime.
3. Read the Pareto on the Downtimes report for the same window. If one category carries most of the loss, the number is correct and the problem is on the floor. See Read the Pareto chart.
4. Read the Unknown Hours card on the Advanced Report. A machine whose sensor was offline half the period has a connectivity problem, not a production one. See Troubleshoot a device that is offline.

You do not need to change the goal to fix this. A goal changes what color a gauge draws, not what it counts, see Set OEE and utilization goals.

Machine shows running when idle

The sensor reports running or stopped, and nothing in between. The state flips when the vibration trace crosses a threshold and stays across it for the momentum interval, so a machine that reads running while it sits idle has a threshold problem rather than a hardware fault.

1. Open the calibration panel and watch the live trace with the machine standing still. Note the highest point the idle band reaches.
2. Raise the Running Threshold to just above that point, leaving a buffer. It is the control that decides where uptime starts.
3. Leave a gap between Running Threshold and Stopping Threshold. A machine whose vibration wanders across a single line flips state on every wander. See Set the running and stopping thresholds.
4. If the state flickers on a machine that is genuinely running, raise Momentum instead. Momentum decides how long motion has to persist. See Set momentum.

Raise the threshold when the state is wrong. Raise momentum when the state is right but unstable. The two look alike on a card and are opposite on the trace.

Confirm the sensor is still attached before touching either. A SenseAi knocked off its mounting surface reads a neighboring machine, see Device is online but sends no data.

Downtime not recorded

A stop everyone on the floor saw, and the report does not carry, was filtered, absorbed or never detected.

Read the machine's activity list before changing any setting. It lists every interval in the window with its start, duration and state, so it tells you whether the platform recorded one long stop, several short ones, or nothing at all. See The activity feed.

Too much unclassified time

Unclassified downtime is still downtime. It counts in full, and no percentage on any screen moves when somebody classifies it, see Downtime. What a backlog costs you is the Pareto: a report whose largest bar reads Unclassified cannot say where the time went.

1. Turn on the Short Downtimes rule first. It removes the majority of a plant's unclassified rows and is the rule least likely to hide something you needed to see. See Short downtimes.
2. Add break windows for lunch and scheduled breaks, which are otherwise classified by hand every day. See Scheduled breaks.
3. Clear the existing backlog with bulk classify. Rules never reach back, so turning one on leaves yesterday untouched. See Bulk classify.
4. If operators are classifying and the backlog still grows, the category list is too long or too vague to pick from. See Design a category list.

Leave the Entire Shift rule off until the shift schedule is trusted. If the schedule says a shift ran when the plant was closed, every machine reads as down for the whole of it, and the rule silently files a shift of real downtime under whatever category you chose.

Shift boundaries look wrong

Production landing in the wrong shift, the wrong day, or split across two of them is almost always a timezone or schedule problem.

1. Open Organization Settings and read Schedule Timezone. Shift boundaries are read against this zone, so a wrong value moves every one of them by the offset between the two. The dropdown lists named zones such as (GMT-05:00) Eastern Time (US & Canada) rather than raw offsets, so the zone carries its own daylight-saving rule.
2. Read the shift times. An overnight shift is one whose end time is at or before its start time, for example 10 PM to 6 AM, and needs no second entry for the morning.
3. Check that shifts do not overlap. The panel states the rule under Work Schedule.
4. Check the days on each shift. A night shift running Friday into Saturday is entered on Friday alone.
5. Rule out the midnight split before calling it an error. Reports divide an overnight shift at midnight unless Shift islands is on, while the Assets page shows it whole, so the two disagree by design. Check the ends of the run rather than the middle: the first day of a run is short, and the day after the last night carries hours, while a day mid-run can total correctly out of two different nights. See Where the overnight hours land.

The timezone and the shifts save together. Click Edit on the Schedules panel, make both changes, then click Save, and a Work shifts modified toast confirms it. There is no way to save one without the other, so read both back before leaving the panel. Full procedure in Shifts and timezone.

The organization timezone. It is the one setting that makes every number wrong at once.

Correcting the zone does not move data that is already recorded. It moves the boundaries that data is read against, so historical reports redraw against the corrected shifts rather than losing anything.

OEE does not match a manual calculation

First, confirm you are comparing the same measure. IoTFlows has no combined OEE figure and no quality factor. It reports availability as uptime and performance as the parts gauge, separately, and nothing multiplies them together. Comparing an IoTFlows uptime of 85% to an OEE of 60% from another system compares one factor to the product of three.

Once you are comparing uptime to availability, four things explain nearly every remaining difference.

For example, a 9-hour shift reading 6 h 30 min uptime and 1 h 30 min downtime is not missing an hour: the sensor was offline for it, and unknown time sits outside both terms. Uptime is 6.5 ÷ 8 = 81%, not 6.5 ÷ 9 = 72%.

Turn Exclude Unknown and Exclude None on when you are comparing machines or holding someone to a number. Leave them off when you are asking where the shift went, because a number that excludes the lunch hour and the dead sensor no longer adds up to the length of the shift. See Choose what the number includes.

Numbers changed retroactively

A figure you read yesterday can legitimately read differently today. Four edits rewrite history, and none of them marks the record.

Three things that look retroactive and are not:

• Classifying a stop. A reason code changes what the Downtimes report can say about the time, not how much of it there is.
• Turning on an auto-classification rule. Rules act on stops recorded after they are enabled and never reclassify the backlog. See What the rules do not do.
• Changing momentum or a threshold. Neither re-scores data already captured, so the old values' states stand until new data arrives.

A live window also moves on its own. A shift in progress recalculates every minute, so a figure read at 10 AM and quoted at 2 PM will not match. Select a completed shift or a past date to freeze it, see Choose the window.

Still stuck

Something went wrong and An error occurred are the platform's generic failures. Either means the request did not complete and nothing was saved, so the setting still holds its old value however the form looks. Retry it, then reopen the panel and read the value back before assuming the change took.

Two symptoms belong elsewhere. A machine missing from a report rather than reading wrong is usually a filter or an access grant, see When a machine is missing. A single silent device is a connection problem, see Troubleshoot a device that is offline.

Otherwise, contact support with the machine, the exact window, the number you expected and the number you saw. The window matters more than the machine: most reports of a wrong figure turn out to be two people reading two different windows.

See also

• Shifts and timezone
• Calibrate SenseAi
• How each metric is calculated
• Classify downtime automatically
• Troubleshoot a device that is offline