---
title: "Troubleshoot wrong utilization or OEE"
description: "Symptom, cause and fix for machine numbers that do not match the floor. Check the organization timezone first, because it is the one setting that moves every number at once while leaving each one looking plausible. Then the shift schedule, then the window and the Exclude switches on screen, then the machine's own status bar, where gray means the sensor was silent and red means it was stopped. Also covers uptime that reads too high or too low, stops that never appear, unclassified backlog, and the four edits that rewrite history."
category: "Reference"
source_url: "https://www.iotflows.com/docs/monitoring/troubleshoot-monitoring/"
---
# 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](/docs/monitoring/metrics-reference/).

## Start here: four checks
Diagram: 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.

*My numbers look wrong: the four branches, starting with the organization timezone.*

**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.

| Symptom | Likely cause | Check | Fix | Page |
|---|---|---|---|---|
| Uptime higher than the floor believes | Short stops converted to uptime | The machine's **Treat short downtimes as uptime** toggle | Turn it off, or raise the cutoff | [Utilization too high](#too-high) |
| Uptime lower than the floor believes | Shift schedule longer than the plant runs | **Work Schedule** against the real calendar | Shorten the shift, or classify the edges | [Utilization too low](#too-low) |
| Machine reads running while it sits idle | Running threshold below the idle band | The vibration trace against both thresholds | Raise the running threshold | [Running when idle](#running-when-idle) |
| A stop everyone saw is not in the report | Uptime filter, downtime filter, or a rule | The machine's filter values, then the activity list | Lower the filter, or split the activity | [Downtime not recorded](#missing-downtime) |
| Half the shift is unclassified | No automatic rules, or none that fit | **Auto-Downtime Classifications** | Turn on short downtimes first | [Too much unclassified time](#unclassified) |
| Production lands in the wrong shift or day | Timezone, or an overnight shift misdefined | **Schedule Timezone**, then the shift times | Correct the zone, then the shifts | [Shift boundaries](#shift-boundaries) |
| Your spreadsheet and the dashboard disagree | Unknown time, None breaks, or window averaging | What the window excludes | Recompute on the platform's definition | [Manual calculation](#manual-check) |
| A number you read yesterday has moved | Backfill, deleted data, or a calibration change | Who changed what, and when | Nothing to fix, but know the cause | [Numbers changed](#retroactive) |

## 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](/docs/hardware/calibrate-senseai/#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](#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](/docs/monitoring/metrics-reference/#none).
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](/docs/hardware/calibrate-senseai/#uptime-filter).

**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](/docs/monitoring/downtimes/#pareto).
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](/docs/hardware/troubleshoot-offline-device/).

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](/docs/monitoring/oee-goals/#choosing).

## 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](/docs/hardware/calibrate-senseai/#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](/docs/hardware/calibrate-senseai/#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](/docs/hardware/troubleshoot-offline-device/#no-data).

> **Info:**
> **Reading a BeamTracker instead?** It decides state from parts crossing a beam rather than from vibration, so the equivalent controls are detection distance and minimum object thickness. See [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values).

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

| Where it went | How to tell | What to do |
|---|---|---|
| Converted to uptime | The stop was shorter than the machine's cutoff and the toggle is on | Raise the cutoff, or turn the toggle off, in [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) |
| Absorbed by the downtime filter | A BeamTracker whose downtime filter exceeds the gap between parts | Lower the value in [Set the downtime filter](/docs/hardware/calibrate-beamtracker/#downtime-filter) |
| Never detected | The machine kept vibrating while it was not producing | Raise the running threshold in [Calibrate SenseAi](/docs/hardware/calibrate-senseai/#thresholds) |
| Recorded as unknown | The sensor was offline for the stretch | The bar is gray, not red. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/#stopped-or-offline) |
| Outside the window | The stop crossed a shift boundary or the date you selected | Widen the window, or clear the shift filter, in [Choose the window](/docs/monitoring/assets-overview/#window) |
| Merged into a longer stop | One stop on the record covers two real events | Split it in [Split a downtime](/docs/monitoring/classify-downtime/#split) |

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](/docs/monitoring/asset-detail/#activity).

## 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](/docs/monitoring/metrics-reference/#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](/docs/monitoring/auto-downtime-rules/#short-downtimes).
2. Add break windows for lunch and scheduled breaks, which are otherwise classified by hand every day. See [Scheduled breaks](/docs/monitoring/auto-downtime-rules/#breaks).
3. Clear the existing backlog with bulk classify. Rules never reach back, so turning one on leaves yesterday untouched. See [Bulk classify](/docs/monitoring/classify-downtime/#bulk).
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](/docs/monitoring/downtime-categories/#design).

**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](/docs/admin/shifts-and-timezone/#overnight-hours).

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](/docs/admin/shifts-and-timezone/).

![The Schedules panel in Organization Settings. A row labeled Schedule Timezone holds a dropdown reading a GMT offset followed by a named zone, highlighted with a violet box. Below it, a Work Schedule row lists each shift with its name, its days abbreviated to three letters, and its start and end times](/images/monitoring/mon-trouble-02.webp)

*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.

| Difference | Why | Where it is decided |
|---|---|---|
| The hours do not add up to the shift | Unknown time counts toward neither uptime nor downtime | [Unknown time](/docs/monitoring/metrics-reference/#unknown) |
| A break is missing from the total | **Exclude None** removes None-severity stops from both terms | [The None severity](/docs/monitoring/metrics-reference/#none) |
| A multi-shift window is not the average of its shifts | The window is calculated whole, so a longer shift contributes more minutes | [Production metrics](/docs/monitoring/metrics-reference/#production) |
| Short stops are missing from downtime | The machine converts them to uptime | [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) |

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](/docs/monitoring/advanced-report/#switches).

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

| Edit | What moves | Where it is done |
|---|---|---|
| Backfilling a count | Production counts, the parts gauge and FPY for that window, permanently. See [Production counts and backfilling](/docs/monitoring/asset-detail/#backfill) | **Modify Counts** on the machine page |
| Deleting the last N hours of data | Uptime, downtime and every count for that window, with no undo. See [Delete the last N hours of data](/docs/monitoring/edit-assets/#delete-data) | **Delete Data** on the Assets page, Owner or Administrator |
| Changing the uptime filter or the short-stop cutoff | Uptime and downtime for stops older than about 30 minutes, because both settings reach back rather than applying only to new data | The machine's calibration panel |
| Deleting or splitting an activity | The shape of the timeline for that stretch. See [Delete an activity](/docs/monitoring/classify-downtime/#delete) | The activity list on the machine page |

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](/docs/monitoring/auto-downtime-rules/#limits).
- **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](/docs/monitoring/assets-overview/#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](/docs/monitoring/assets-overview/#missing). A single silent device is a connection problem, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/).

Otherwise, [contact support](/docs/get-started/get-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](/docs/admin/shifts-and-timezone/)
- [Calibrate SenseAi](/docs/hardware/calibrate-senseai/)
- [How each metric is calculated](/docs/monitoring/metrics-reference/)
- [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/)
- [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/)