Availability is the first of the three factors that multiply together to form OEE, and it answers a deceptively simple question: of the time this equipment was supposed to be producing, how much of it actually was? The subtlety is entirely in what counts as time it was supposed to be producing, because that decision determines what shows up as a loss and what is excluded before the calculation even begins. This guide defines the OEE availability rate precisely, shows how planned and unplanned downtime are separated, and explains how SCADA state tags and downtime reason codes drive it.
Availability Rate (OEE) in one line: The availability rate in OEE is run time divided by planned production time, expressed as a percentage. Planned production time is the time the equipment was scheduled to run after subtracting planned non-production such as no orders or scheduled breaks, and run time is that planned time minus unplanned and setup downtime. Availability therefore isolates the effect of stops that occurred when the equipment should have been running, and it is the OEE factor most directly driven by breakdowns and changeovers.
Availability is defined as run time divided by planned production time. Planned production time starts from all the time in the period and subtracts the intervals when the equipment was never expected to run, such as unstaffed shifts, scheduled maintenance windows, or periods with no orders. What remains is the time management committed the equipment to producing, and it is the honest denominator against which stops should be judged. Excluding time the equipment was never meant to run keeps availability from being penalized for a deliberate choice not to produce.
Run time is then planned production time minus the downtime that occurred within it: the breakdowns, minor stops long enough to register, and setup or changeover time. Dividing run time by planned production time gives availability as a fraction, so an asset scheduled for eight hours that actually ran for seven has an availability of about 0.875, or 87.5 percent. The remaining time is availability loss, and in the Six Big Losses framework it decomposes into breakdown loss and setup/adjustment loss.
The reason the boundary between planned and unplanned time matters so much is that it decides whether a stop counts against availability at all. Time excluded from planned production time does not depress availability, while time inside it does. Setting that boundary consistently is therefore a precondition for a meaningful availability number, and it is also where organizations most often disagree, because whether to count, say, a planned changeover as a loss or as excluded time changes the metric's message.
Not all stops are equal, and availability is most useful when it distinguishes downtime the operation chose from downtime it suffered. Planned downtime, such as scheduled maintenance, sanitation, or a shift with no production scheduled, is generally excluded from planned production time so that availability reflects only performance against the commitment to produce. Unplanned downtime, such as a breakdown or an unexpected material shortage, falls inside planned production time and reduces availability, because it represents the equipment failing to run when it was supposed to.
Changeovers occupy a debated middle ground. A setup or changeover is planned in the sense that it was expected, but the equipment is genuinely not producing during it, and OEE conventionally treats setup and adjustment as an availability loss rather than as excluded time. The important thing is not which convention a site adopts but that it applies one consistently, because comparing availability across lines or over time only means something if everyone drew the planned/unplanned boundary the same way.
Edge cases test the definition. Time waiting on an upstream machine, an operator break during a staffed shift, or a slow patch that never fully stops the line each force a decision about whether they belong to availability, to performance, or to excluded time. A common rule of thumb is that if the equipment is fully stopped during committed time it is an availability loss, if it is running slowly it is a performance loss, and if it was never committed to run it is excluded. Documenting these rules is what keeps availability comparable rather than an accident of how each stop happened to be logged.
Availability is the OEE factor most naturally computed from control-system data, because it depends almost entirely on knowing when the equipment was running versus stopped. A run/stop state tag, read live from a PLC or field device, provides exactly that signal, and integrating its state over the planned production time yields run time directly. A cloud SCADA such as Merobix historizes these state tags from the field over Modbus, DNP3, OPC UA, or MQTT, so run time can be measured from the actual behavior of the equipment rather than estimated from operator notes.
The state tag alone gives availability but not diagnosis; that requires downtime reason codes. When each stop is tagged with a reason, the platform can separate breakdowns from setups and, crucially, distinguish downtime that should count against availability from planned windows that should be excluded from the denominator. Without reason codes, a maintenance window and a genuine failure look identical to the raw state tag, and availability becomes ambiguous. Reason coding is what lets the same data support both the number and the story behind it.
Because the platform records these signals continuously and time-stamps them, availability can be calculated over any window and trended, so a team sees whether a low figure comes from a few long breakdowns or many short ones, and whether it is drifting. That continuous record also handles the awkward edges cleanly: a documented rule for how a given reason code is treated, applied automatically to historized events, keeps the planned/unplanned boundary consistent across every shift and every asset rather than left to whoever filled in the log.
Availability is run time divided by planned production time. Planned production time is the total time minus periods when the equipment was never scheduled to run, and run time is that planned time minus unplanned and setup downtime. The result is the fraction of committed production time during which the equipment actually ran, expressed as a percentage.
Planned downtime, such as scheduled maintenance or an unstaffed shift, is generally excluded from planned production time, so it does not reduce availability because the equipment was never committed to run then. Unplanned downtime, such as a breakdown or unexpected shortage, falls inside planned production time and reduces availability because the equipment failed to run when it was supposed to. Setups are usually treated as an availability loss even though they are expected, so the key is applying the boundary consistently.
No. Availability only counts whether the equipment was running or stopped during committed time; it does not care how fast it ran. Running below the ideal rate is a performance loss, not an availability loss, so a machine that never stops but runs slowly can have high availability and still have a low overall OEE. Keeping speed losses out of availability is why the three OEE factors have to be calculated separately.
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.