How ProAlert Measures OEE Availability

How Availability data is entered

Is the data behind Availability (production quantity, run start and stop, downtime) collected automatically from the equipment, or entered by hand by team members at the touchscreen?

ProAlert™ deliberately splits the two: what the machine knows, the machine reports. What only a person knows, a person enters.

A ProAlert EdgeSense device mounted at the machine reads a cycle signal directly from the equipment and streams each cycle to the server as it happens. What no sensor can know is why a machine stopped, so that judgment stays with the team, entered on the touchscreen at the asset in one or two taps.

Timestamps are never typed

In every case above, the time is stamped by the ProAlert server in UTC (Coordinated Universal Time) at the moment the event is received. Operators press a button; they do not enter times after the fact. Each record also carries the user and the moment it was created, and is retained as an audit trail.

What the system detects on its own

EdgeSense also watches the cycle stream for two conditions and raises them without being asked: a lull, meaning no cycle within a configured number of minutes, and slow production, meaning the rolling cycle time has drifted past a configured threshold. These raise a visible status so a stop gets noticed and categorized. They do not silently create a downtime record, because the reason still has to come from a person.

How downtime is recorded and timed

How is downtime recorded, and what determines the start time and the end time of a downtime event?

Downtime is not a figure that is entered. It is a record with a start and an end, and ProAlert holds two kinds, plus one record that accounts for the time nobody was scheduled to run.

Time between runs within a shift is a different thing and is recorded as such: when the team switches products, the operator starts a Product Change Over, which is a planned downtime type. Changeover time is therefore visible and reportable in its own right rather than disappearing into a gap.

The rules that keep the number honest

Unplanned downtime is timed independently. A downtime call carries its own start and stop. It is not bounded by the start and stop of runs or of planned downtime, so a stoppage is timed by what actually happened at the machine rather than by the shape of the shift around it. A stoppage that begins on one shift and is not resolved until the next is therefore held as one event, not two fragments. Its true duration survives the shift change intact, which is what makes mean time to repair (MTTR), reason history and repeat failure analysis meaningful. For the Availability figure, that event is charged to the run it began in, up to the point that run closed.

Open calls accrue live. An unresolved downtime call counts against the current run continuously, and every dashboard, tablet and web view refreshes on a broadcast cycle of roughly ten seconds. Nothing waits for the call to close before the number moves.

A machine can be down for more than one reason at once. ProAlert deliberately allows concurrent downtime calls, so the team can log every contributing reason and the plant gets an accurate downtime history to analyze. Availability is charged the total elapsed duration of the stoppage, counted once. Logging three reasons does not cost three times the availability.

Planned time inside unplanned time is netted out. If a scheduled break falls while the machine is already down, the overlapping minutes are removed from the unplanned total, which offsets the effect of that stoppage on Availability. The plant is not penalized twice for minutes it was never going to run.

Downtime is clipped to its run. Only calls that begin within a run count against that run, and the segment is trimmed to the run window. A call raised in a previous shift cannot bleed into today's figure.

Not every call is downtime. Each call type carries a downtime flag. A material request or a quality question that does not stop the machine is logged and escalated, but never touches Availability.

Which clock Availability runs against

Is the production time used to calculate Availability based on the planned production schedule, or on the actual start and stop times of the run?

It is based on the production run, that is the Start and Stop of the run itself, not on the planned schedule.

While a run is open, Run Stop is simply the current time, so the figure moves second by second. Over a shift, a day or a month, ProAlert totals the parts rather than averaging the percentages: it sums Operation Time across every run in the period and divides by the summed Planned Production Time. A two minute run therefore cannot carry the same weight as an eight hour one.

The effect is that Availability answers a specific question: of the time we were set up and committed to produce, how much of it did we actually produce? Whether the floor was opened up for the right hours in the first place is a scheduling question, measured separately and reported next to it.

An extended stoppage, then the team goes home

If an extended stoppage occurs after production has started, and team members are sent home before the scheduled end of the shift, how is the remaining scheduled time handled? Is it recorded as planned downtime, unplanned downtime, or in some other way?

It is handled in a third way: the clock stops, and the remaining hours are accounted for as Scheduled Not to Run. The stoppage counts as unplanned downtime for as long as the team was there. The hours after they leave are not charged to the machine as either kind of downtime, but neither do they vanish.

When the operator taps End Shift, ProAlert closes the run at that instant, closes any open break, and opens an End of Shift record that stays open until the next shift starts. That record is what lets ProAlert account for every moment of the shop floor day: the floor is either running, on planned downtime, on unplanned downtime, or scheduled not to run. There is no unaccounted time.

Note also that the stoppage itself is timed independently. The downtime call has its own start and stop and is not bounded by the run, so it began at the failure and stays a single event even if it is still open when the next shift arrives. It is charged to Availability up to the moment the run closed, while the event itself remains whole for reliability analysis.

Worked example

The shift is configured 06:00 to 14:00 with a 30 minute lunch. The team comes in ahead of the schedule and starts running at 05:45. The machine fails at 11:15, cannot be recovered, and the team is released at 13:00.

The same day, accounted against the schedule

Availability describes the machine. The schedule comparison describes the plan. ProAlert reports both, and the second is where the early start and the early release show up.

If your policy is to measure against the full scheduled shift

Some plants want the released hour to sit inside the metric rather than beside it. ProAlert supports that without any change to the software, through how the shift is closed out.

Both routes record the same 300 minutes of actual Operation Time. What differs is the denominator, which is a management decision about what the plant holds itself accountable for, not a limitation of the system. Planned downtime types are configurable per site, so a category such as Released Early or No Demand can be added and reported on separately.

Where Availability sits in the wider OEE figure

Availability is one of the three components of OEE (Overall Equipment Effectiveness). Performance is driven by the cycle rate target held per product and machine, Quality by the scrap entered against the run. The composite figure is the product of all three.

Figures in the worked example are illustrative. Behavior described applies to the ProAlert 2026 release.