Availability tells you whether a machine was running; performance tells you how fast it ran while it was. It is the middle factor of OEE, and it captures the productivity quietly lost when equipment operates but at less than its ideal speed, whether from a deliberately low setpoint, wear, or a stream of interruptions too brief to count as downtime. This guide defines the OEE performance rate against an ideal cycle time or nameplate rate, explains why speed losses and micro-stops are so hard to detect, and shows how count-rate data in a historian exposes slow running.
Performance Rate (OEE) in one line: The performance rate in OEE measures how fast equipment ran compared with how fast it ideally could have, calculated as the actual output divided by the output the run time should have produced at the ideal cycle time or nameplate rate. Equivalently, it is ideal cycle time multiplied by total count, divided by run time. Performance isolates speed loss and minor stops, the productivity lost while the machine was running but not at full rate, and it is the OEE factor most likely to be understated because slow running rarely announces itself.
Performance is defined relative to a reference speed: the ideal cycle time, meaning the shortest time in which the equipment can produce one unit under optimal conditions, or equivalently the nameplate rate expressed as units or volume per unit time. The performance rate is the ratio of what the machine actually produced to what it would have produced during its run time at that ideal rate. A common form is ideal cycle time multiplied by the total count, divided by run time, which yields a fraction that is one when the machine ran at full speed and less than one when it ran slow.
Choosing the ideal rate is the crux of a credible performance number. It should be the best sustained rate the equipment can genuinely achieve, not an inflated theoretical figure and not the average it happens to run at, because using the actual average as the ideal would make performance always look perfect and hide the very losses the factor exists to reveal. The nameplate rate from the manufacturer is a common starting point, refined by the best rate the equipment has demonstrably sustained.
Because performance uses run time as its basis, it deliberately excludes the time the machine was fully stopped, which availability already accounted for. This separation is what keeps the factors from double-counting: a stop is an availability loss, and slowness during the time the machine did run is a performance loss. Multiplying the two, and then quality, is how OEE combines them without any loss being counted twice.
Performance losses are the stealthiest of the Six Big Losses precisely because the equipment never stops in a way anyone notices. Reduced speed loss is continuous: a line running at ninety percent of its rated rate looks entirely normal to an operator watching it, and produces no alarm, no downtime record, and no obvious symptom, yet it quietly forfeits a tenth of its capacity every hour. Unless someone compares the actual output against the ideal, that loss is invisible in the daily rhythm of the plant.
Micro-stops, also called small stops or idling losses, are the other half of the hidden performance problem. These are interruptions brief enough to clear before anyone logs them, a momentary jam that an operator clears in seconds, a photo-eye false trip, a short starve from upstream, and each is individually negligible. Their damage is cumulative and only visible in aggregate: dozens or hundreds of tiny pauses across a shift can add up to a large slice of lost output while never appearing as a single meaningful downtime event.
The consequence is that a plant can have strong availability and quality and still see a mediocre OEE, with the whole shortfall sitting in performance. Teams that look only at recorded downtime and reject counts will find nothing wrong and conclude the number must be pessimistic, when in fact the loss is real and lives in the gap between actual and ideal rate. Confirming that gap requires rate data, not event data, which is why performance so often stays undiagnosed without the right measurement.
Detecting performance loss means comparing the actual production rate against the ideal rate at fine time resolution, and that is a job for a historian. A count tag that increments per unit, or a flow tag measuring volume per unit time, read from the field and logged continuously, gives the actual rate over run time. Dividing that by the ideal rate yields performance, and, more usefully, plotting it over time shows exactly when the equipment ran slow rather than just that it did on average.
A cloud SCADA such as Merobix historizes these count and flow tags read over Modbus, DNP3, OPC UA, or MQTT, which turns the two hidden losses into visible ones. Sustained reduced speed appears as a rate trend sitting persistently below the ideal, and micro-stops appear as a rapid sawtooth of the count rate dropping to zero and recovering, brief enough that no downtime record was ever created but plainly present in the high-resolution trace. Seeing that pattern is what lets a team attribute a low performance factor to the right cause.
Because the data is continuous and time-stamped, the analysis scales beyond a single machine and a single shift. A team can rank assets by performance loss, correlate slow patches with product changes or shifts or upstream conditions, and confirm whether an improvement actually restored the rate. The same live count and flow signals used to run the process thus become the evidence base for the one OEE factor that is otherwise almost impossible to pin down.
Performance is the actual output divided by the output the run time should have produced at the ideal cycle time or nameplate rate. A common form is ideal cycle time multiplied by the total count, divided by run time, which gives a fraction that is one when the machine ran at full speed and less than one when it ran slow. It uses run time rather than total time so that stops, which availability already counts, are not counted again.
Ideal cycle time is the shortest time in which the equipment can produce one good unit under optimal conditions, and it is the reference speed the performance rate is measured against. It should be the best rate the machine can genuinely sustain, based on the nameplate rate and demonstrated best performance, not the average rate it actually runs at. Using an honest ideal is essential, because setting it to the actual average would make performance always appear perfect and hide the speed losses the factor is meant to reveal.
Speed loss and micro-stops occur while the equipment is running, so they never create a downtime record or an obvious symptom. A line running slightly below its rated rate looks normal, and micro-stops clear too quickly to be logged, so both are invisible in event data such as downtime and reject counts. Detecting them requires comparing the actual production or flow rate against the ideal rate at fine time resolution, which typically means using a historian to trend the count rate over time.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.