Detecting anomalies in energy consumption data

Most wasted energy does not announce itself. It hides in a baseload that has crept up a few kilowatts, a rooftop unit that never shuts off on weekends, or a meter that started reporting garbage two weeks ago and nobody noticed. Monthly bills roll all of that into a single number that looks roughly normal. The anomaly is real, it is costing money, and the summary hides it. Finding these patterns in consumption and interval data, before they show up as a surprise on a bill, is one of the highest-value things an energy team can do with data it already has.

This piece is about anomalies in interval and time-series consumption data: usage that deviates from expected behavior. It is not about billing errors or line-item overcharges, which are a different problem covered in utility bill anomaly detection. Here we focus on what the meter recorded, not what the utility charged.

What counts as an energy anomaly

An energy anomaly is consumption that departs from what the building or process should be doing under the current conditions. Some are gradual, some are sudden, and some are not real usage at all but faults in the data. The common types:

• Baseload creep: the overnight or always-on floor of consumption drifts upward over weeks, usually from equipment schedules that quietly stopped working or new loads nobody accounted for.
• Equipment left on: a system that should cycle off keeps running, showing up as flat consumption during hours that should be near baseload.
• After-hours and weekend usage: demand that stays high when the building is unoccupied, often the single largest recoverable waste in a commercial site.
• Sudden spikes: a step change in demand from a new load, a failed control, or a simultaneous startup that also drives peak demand charges.
• Meter faults: stuck values, sudden zeros, negative reads, or impossible jumps that signal a metering or communications problem rather than real consumption.
• Data gaps: missing intervals that, if ignored, quietly bias every average, baseline, and total you calculate from the series.

Why interval data beats monthly bills for this

You cannot find an after-hours pattern in a number that covers a whole month. Resolution is the entire game. A monthly bill gives you 12 data points per year, while a smart meter produces over 35,000. That is the difference between knowing you used more energy in July and knowing that a chiller ran every night from 2 a.m. to 5 a.m. for three weeks.

Monthly data confirms that something changed. Interval data tells you when, how often, and often what, which is what you need to actually fix it.

Detection methods practitioners actually use

You do not need deep learning to catch most anomalies. The methods that earn their keep in day-to-day energy work are transparent and explainable, which matters when you have to justify an alert to an operations team.

Baseline plus weather normalization

Because so much of energy use tracks weather, the first step is to normalize it out. Measurement and verification practice does this by adjusting both the baseline and the reporting period to a common set of conditions, often typical meteorological year weather data representing long-term averages. The GHG Protocol and M&V frameworks both lean on a regression baseline built from drivers like temperature. The deeper mechanics are in weather normalization for energy data. Once weather is accounted for, a deviation from the normalized baseline is far more likely to be a real anomaly than a hot day.

CUSUM (cumulative sum)

CUSUM is a workhorse for spotting a persistent shift. You compute the difference between actual and expected consumption each period and accumulate it. As long as usage tracks the baseline the line stays flat, but a small sustained change bends it. In energy monitoring, a rising CUSUM slope indicates savings against baseline while a falling slope indicates an increase in use. Its strength is catching baseload creep: a two-kilowatt drift is invisible in any single reading but obvious once accumulated over weeks.

Day-of-week and hour-of-day profiles

Build the expected shape of a normal day and week from history, then compare each new day against it. Smart-meter analysis routinely extracts features like hour of the day, day of the week, and a weekend indicator precisely because consumption is quasi-periodic. A Tuesday that looks like a Saturday, or a 3 a.m. that looks like a 3 p.m., is an anomaly you can see at a glance in a load profile. Reading these shapes is covered in reading load profiles: baseload and peak.

Statistical thresholds

The simplest approach still works: compute the mean and standard deviation of consumption for comparable periods and flag readings that fall outside a set band, for example beyond three standard deviations. Quantile or interquartile ranges do the same job while resisting the influence of extreme values. Thresholds are cheap, explainable, and effective for catching spikes and stuck-meter faults, as long as they are computed against the right comparison group rather than one global average.

Clean, complete data is the prerequisite

Every method above assumes the series it reads is trustworthy, and that assumption is where most anomaly programs fail. Missing intervals, timestamp irregularities, and sensor inconsistencies are the recurring culprits: researchers note that many analytics models show degraded accuracy due to missing values and timestamp problems. A gap that gets filled with a zero looks like an outage. A baseline built on incomplete history is biased from the start. A daylight-saving shift that nobody handled throws off every hour-of-day profile.

There is also a chicken-and-egg trap: some anomalies are data-quality faults, so your cleaning step and your detection step overlap. The practical answer is to separate the two clearly. Validate the data first, flag faults as faults, and only then run consumption-anomaly detection on the clean series. Comparing the two views is easier when you understand interval data versus monthly bills.

• Complete: every interval present, with real gaps flagged rather than silently zero-filled.
• Aligned: consistent timestamps and time zones, including daylight-saving transitions.
• Validated: stuck, negative, and physically impossible values caught before analysis.
• Continuous: a long enough clean history to build a stable baseline and seasonal profile.

How MartinAI helps

MartinAI is a Canadian utility-data platform that collects utility data from utility connections, Green Button feeds, and scanned or PDF bills, then cleans and standardizes it into one continuous, validated dataset. That is the foundation anomaly detection needs: aligned timestamps, flagged gaps, caught meter faults, and enough clean history to build a real baseline.

With that foundation in place, the baseline, CUSUM, profile, and threshold methods described here run on data you can trust, so an alert points to a genuine operational issue instead of a hole in the data. The goal is to end the manual cleanup that usually eats the time you would rather spend investigating what the anomaly is telling you.