Average number of hours per day that the RTU compressor was actively running. The baseline signal for operational health — flags equipment running too long or too short before the pattern becomes a larger issue.
Average number of hours per day that the RTU compressor was actively running during the analysis period.
The calculation method may vary depending on the data available for each client and site. Ideally, runtime is determined from a direct compressor-on signal available through the thermostat or BMS integration.
When this signal is not available, proxy methods can be used — most commonly, identifying active intervals based on energy consumption data (kW per interval) where power exceeds an estimated compressor-on threshold. The specific threshold will depend on the equipment model and installation.
The exact calculation logic may vary by client depending on available data sources, sensor configuration, and integration type.
The following ranges are provided as reference examples only. They should be reviewed and adjusted for each client based on their type of operation, store format, climate zone, and any specific agreements in place. A 24/7 convenience store in California will have a very different expected runtime profile than a bank branch that operates until 2pm.
| Range | Classification | Interpretation |
|---|---|---|
| < 4 h/day | Possible low issue | Equipment may be offline, metering gap, or extremely mild weather |
| 4 – 14 h/day | Expected (climate-dependent) | Normal operating range for most retail formats in temperate climates |
| 14 – 20 h/day | Elevated — monitor | May reflect high ambient temperatures, scheduling issue, or early equipment degradation |
| > 20 h/day | Excessive — flag for review | Persistent high runtime warrants investigation; possible equipment or setpoint problem |
Reference ranges only. Calibrate per client based on store format, operating hours, and climate zone before activating compliance reporting.
The target percentage of sites in compliance (reference: 85%) should be defined and agreed upon with each client. This default is used as a starting point only.
Runtime is one of the four HVAC optimization metrics Keedian tracks. The table below shows how moving this metric impacts each of the four customer value drivers the product is designed to improve. These are the same four levers expressed on every HVAC product page as Expected Outcomes — the metric pages explain the mechanism; the product pages express the magnitude.
| Value driver | Impact strength | How Runtime moves this lever |
|---|---|---|
| Energy savings | Direct, primary | Compressor on-hours are the dominant driver of HVAC kWh. Catching and correcting excess runtime — overcooling, after-hours operation, override-driven 24/7 operation, persistent short cycling — is the most direct lever to reduce HVAC energy spend. |
| Avoided truck rolls | Indirect, leading indicator | Abnormal runtime patterns (sudden increase, sustained short cycling, runtime against schedule) surface days or weeks before a comfort complaint. Acting on the signal enables remote remediation or scheduled maintenance instead of an emergency dispatch. |
| Asset lifespan | Direct, strong | Compressor wear correlates with run-hours and start-stop cycles. Identifying runaway runtime — continuous operation, persistent short cycling — and correcting the root cause extends useful equipment life. |
| Customer experience | Indirect, predictive | Sustained high runtime signals the system is struggling to hold setpoint — comfort failure usually follows. Very low runtime under load means the system is effectively offline, with discomfort to follow. Runtime is a leading indicator of comfort issues, not a direct CX metric (Temperature Compliance is). |
The table below summarizes the principal alarms that fire directly from Runtime. Each row links to the full operational detail (trigger, preconditions, action plan, human role, linked SOPs) in the SOPs catalog. These are single-metric alarms only — composite FDD that combines multiple metrics with control state and weather context will appear in a future release.
| Alarm | Description | Severity | Tier | AI executes? | Value drivers | SOP |
|---|---|---|---|---|---|---|
| Excessive runtime | RTU runs more hours per day than the expected range for the site profile. | Medium | Essential | Hybrid | Energy savings · Asset lifespan | Open SOP → |
| No runtime when expected | RTU is silent during its scheduled operating hours with communications confirmed healthy. | High | Essential | Hybrid | Customer experience · Avoided truck rolls | Open SOP → |
| Off-schedule operation | RTU is running outside its agreed operating window — override, schedule drift, or manual operation. | Low | Optimized | Yes | Energy savings | Open SOP → |
Roadmap (single-metric): short cycling, runtime degradation trends. Composite alarms in development (multi-metric FDD): refrigerant slow leak, coil ice, economizer stuck closed, capacity vs load mismatch, compressor failure imminent.
The action plan for each alarm lives on its own SOP page in the SOPs catalog — with the diagnostic steps, human role, value drivers, and escalation criteria specific to that alarm. The list below maps each runtime-derived alarm to its SOP; this page keeps only the cross-alarm items that don't belong to a single SOP (data quality, external context).
If runtime values look implausible or contradict the platform-layer comms-health signal, escalate internally to the technical team before treating any alarm as real. Do not report the affected site as non-compliant in the MBR until the data issue is resolved. Document the suspected problem and the period affected so it can be excluded or corrected in the compliance calculations.
If multiple sites in the same region show a similar runtime pattern in the same period, present this as expected behavior rather than a compliance failure. Note the context in the MBR; include outdoor temperature data if available to support the explanation. This is a portfolio-level pattern; it does not need to be escalated to a single SOP.
Per-alarm escalation criteria live in the Escalation block of each SOP in the SOPs catalog. The patterns below are metric-level — they are read from the portfolio view, not from any single alarm firing, and don't belong to a single SOP.
Escalation criteria and communication protocols should be defined as part of the operational agreement with each client. The guidelines below are a general reference and should be adapted to the specific terms, SLAs, and relationship dynamics in place for each account.
Average compressor hours per day while actively running during the analysis period. Flags equipment running too long — possible scheduling issue, equipment degradation, or extreme weather — and too short — possible metering gap or equipment offline. Reviewed monthly in MBR and weekly for worst performers; real-time alert available for sustained excessive runtime events.
SOPs linked to this metric will be documented here. Each SOP will describe the step-by-step operational procedure for a specific scenario identified in the Alarms and Actions sections above.