Availability

Of the time the asset was supposed to run, how much could it actually run?

Current value (maintenance case data): 95.7% - ! Watch. Open the case.

Field	Value
Definition	Scheduled hours minus unplanned downtime, divided by scheduled hours. Planned stops (preventive maintenance) are excluded from the scheduled time.
Formula	(sum(scheduled_hours) - sum(unplanned_downtime_hours)) / sum(scheduled_hours)
Unit	%
Granularity	Asset x month.
Direction	Higher is better ↑
Target and thresholds	≥ 97.0% (amber ≥ 95.0%)
Parameters	–
Owner	Maintenance Manager
Source	Process data (UCI AI4I 2020) + work-order generator
Input	table asset_periods, columns scheduled_hours, unplanned_downtime_hours
Recommended chart	line - Monthly trend against target; one line per asset class at most.
Related KPIs	Mean time between failures (MTBF), Mean time to repair (MTTR)

How to read it

The outcome KPI that operations feels. Decompose it: low availability with high MTBF is a repair-speed problem (MTTR); with low MTBF it is a reliability problem.

Common misreadings

• Different definitions of scheduled time (24/7 vs shifts) make plants incomparable; state the denominator.
• Excluding "minor stops" under a few minutes can hide a large share of lost time.

Worked example (from the test suite)

scheduled_hours	unplanned_downtime_hours
160.0	8.0
160.0	0.0

Expected result: 97.50%. (320 - 8) / 320 = 312 / 320 = 0.975.

This example is asserted in tests/test_formulas.py against the Python function and in tests/test_sql.py against the SQL below.

Implementations

Python function (the single implementation used by the site):

@kpi("availability")
def availability(df: pd.DataFrame) -> float:
    scheduled = df["scheduled_hours"].sum()
    return safe_ratio(scheduled - df["unplanned_downtime_hours"].sum(), scheduled)

Reference SQL (tested on SQLite):

SELECT CAST(SUM(scheduled_hours) - SUM(unplanned_downtime_hours) AS REAL) / SUM(scheduled_hours)
FROM asset_periods