Average hours per day each circuit was on — the absolute version of utilization. Kept as its own metric because it drives lamp-life prediction (LEDs are rated in hours) and utility-rebate validation (efficiency rebates are conditional on minimum burn hours).
Average hours per day each lighting circuit was on, averaged across the spaces in scope. At portfolio level, the percentage of sites whose burn-hour average falls within the per-space band. It is the absolute version of Utilization — the same on/off signal expressed in hours per day instead of a percentage — kept as its own metric because burn hours, not percentages, are what lamp-life planning and rebate validation work from.
Burn hours are derived from the same per-circuit on/off state as Schedule Compliance and Utilization. For each circuit, burn_hours_day = sum(intervals ON) × interval_duration, then burn_hours_avg = burn_hours_day / number_of_days over the period. The per-circuit average is rolled up to the space and the site.
At portfolio level the metric reports the share of sites in band — each site's average compared against the per-space band agreed for that client. The unit is hours/day at circuit, space, and site level, and a percentage of sites in band at portfolio level.
Burn Hours and Utilization come from the same on/off state and are mathematically equivalent up to the denominator — Utilization divides on-intervals by total intervals, Burn Hours divides on-hours by days. Both are surfaced because operators talk about them differently: one as how much a space is used, the other as how many hours the lamps have run. The exact calculation depends on the metering resolution and the schedule mapped to each circuit.
Cumulative burn hours per circuit are accumulated over time alongside the daily average — this running total is what lamp-life prediction and rebate validation read from, not the per-period average alone.
| Range | Classification | Interpretation |
|---|---|---|
| Sales floor 14 – 18 h/day | Expected (example band) | Typical for sales lighting on a daytime-plus-evening schedule; calibrate to the site's actual operating hours |
| Parking 18 – 24 h/day | Expected (example band) | Often 24 h/day for exterior and parking; photocell-driven spaces follow ambient light, not the clock |
| Back of house 8 – 14 h/day | Expected (example band) | Lower-occupancy areas on a tighter schedule or occupancy control |
| Bathrooms 6 – 12 h/day | Expected (example band) | Intermittent use; commonly occupancy-controlled rather than scheduled |
| Cumulative burn hours approaching the lamps' rated life | Lamp-life threshold — plan relamp | LED and fluorescent lamps are rated in hours; as the running total nears rated life, failures begin to cluster — plan a proactive group relamp |
Bands are examples only — calibrate per client based on each space type's operating hours and control method before activating reporting. Photocell-controlled spaces (exterior, parking) are driven by ambient light, not the clock — exclude them or give them a wide tolerance until ambient-light integration ships.
There is no universal burn-hour target — it is set per client per space. A common framing is the share of sites whose per-space burn-hour average stays within the agreed band (a reference starting point of 85% of sites in band), reviewed and agreed with each client before activating reporting.
The table below shows how moving Burn Hours impacts each customer value driver the product is designed to improve — the metric page explains the mechanism; the product pages express the magnitude.
| Value driver | Impact strength | How Burn Hours moves this lever |
|---|---|---|
| Asset lifespan | Direct, primary | LED and fluorescent lamps are rated in hours, so a consistent burn-hour record per circuit is the direct input to lamp-life prediction. Tracking cumulative burn hours against rated life lets the customer plan a proactive group relamp before failures start to cluster — one scheduled visit instead of a string of one-off lamp-out calls, and full useful life out of every lamp. |
| Avoided truck rolls | Direct, strong | Knowing when a circuit's lamps are near end of life turns reactive, repeat lamp-out dispatches into a single planned group relamp. Burn hours far above the space band with no operational reason also point to a stuck-on circuit or a schedule gap — caught at the meter and reverted or scoped before anyone is sent out. |
| Energy savings | Indirect, supporting | Burn hours read off the same on/off state as Schedule Compliance, so a circuit running far more hours than its space band is usually pure waste — lights left on after close, an exterior circuit on at mid-day. Since lighting is commandable, that excess is reverted to schedule, and every hour removed is energy saved. The primary energy lever is Schedule Compliance; Burn Hours is the absolute view that makes the wasted hours legible. |
The table below summarizes the alarms that fire directly from Burn Hours. Each row links to the full operational detail (trigger, preconditions, action plan, human role, escalation, prevention) in the SOPs catalog.
| Alarm | Description | Severity | Tier | AI executes? | Value drivers | SOP |
|---|---|---|---|---|---|---|
| Lamp life threshold approaching | Cumulative burn hours on a circuit approach the lamps' rated life — failures will start to cluster, and the burn-hour record is the evidence for an efficiency rebate. | Low | Essential | Hybrid | Asset lifespan · Avoided truck rolls | Open SOP → |
More alarms in development (single-metric): a relamp-lead-time alarm that schedules the group relamp ahead of the rated-life threshold, and a burn-hour-vs-band watch as a standalone alarm. Composite alarms in development combine burn hours with Schedule Compliance and Utilization — and, once ambient-light integration ships, with photocell state — to separate a wrong template from a local control fault automatically and to attribute wasted hours to the exact circuit.
The action plan for each alarm lives on its own SOP page in the SOPs catalog — with the diagnostic steps, human role, value drivers, escalation, and prevention specific to that alarm. The list below maps each alarm to its SOP.
Lighting is commandable. When a circuit's burn hours run well above its space band because it is on against schedule, the response is an automatic revert to the scheduled state first — clearing the override where controls allow — then investigate local control only if the revert does not hold. A circuit that keeps running after auto-revert is a local fault (manual switch, stuck contactor, photocell drift, unsynced time clock) and is scoped for a maintenance check. This mirrors the per-alarm action plan; the metric-level point is that high burn hours are reverted, not just reported.
Before dispatching anyone, separate the two causes. If the same space type runs high across many sites, the schedule template is wrong for that space — fix it centrally and propagate to every affected space in the same cycle; do not send technicians. If one site only runs high, it is a local control fault — scope a maintenance check at that site. Treating a template error as a fleet of independent dispatches wastes truck rolls; treating a local fault as a template change leaves the real problem in place.
Exterior and parking circuits on a photocell are driven by daylight, so their burn hours vary with the season and a clock-based band will read them as out of range. Exclude these spaces from burn-hour banding, or give them a wide tolerance, until ambient-light integration ships — so a long winter night is not flagged as waste. Document which circuits are photocell-controlled so they are scoped correctly.
Where an LED-retrofit efficiency rebate is conditional on minimum burn hours, the cumulative burn-hour record per circuit is the proof the condition is met. Keep the record current and exportable so it can be submitted as rebate evidence — and so a relamp or circuit change that resets the running total is logged, not lost. This is documentation hygiene, not a per-SOP dispatch.
Per-alarm escalation criteria live in the Escalation block of each SOP in the SOPs catalog. The patterns below are metric-level — read from the portfolio view, not from any single alarm firing.