Solar Monitoring Reports: What Owners Should Get

A solar system can be monitored every day and still leave its owner in the dark. The panels produce, the inverter runs, and the app shows a number, but none of that is management until somebody turns it into a record the owner can act on. That record is the monitoring report, and solar monitoring reports are the part of solar ownership most owners never think to ask about until something has already gone wrong.

A good report does not just say the system produced electricity. It says how much it produced against what it should have produced, how much time it spent working and how much it spent down, which alerts fired and why, and what is still missing from the data. An owner who gets that, regularly, can spot a problem while it is still small. An owner who gets only a monthly total finds out about a fault the way owners always have: from a bill that no longer makes sense, weeks after the generation was lost.

What a monitoring report should show

A report is only useful if it answers the questions an owner would ask after reading it. Four things belong in every report, and if any of them is missing, the report is incomplete however polished it looks.

Production against expectation

The first figure in a report should never stand alone. A production total means little without the figure it is measured against: what the system was expected to produce in that period, under those conditions. Expected production is not a guess; it comes from the system's size, its past performance in similar conditions, and the weather the period actually had. A system that produced less than expected in a cloudy month may be perfectly healthy. A system that produced its usual total while one string was down for a week is not, and only the comparison shows it.

This is also where a report earns its keep over time. One month's comparison is a snapshot. Twelve months of comparisons show a pattern: a slow drift downwards, a season that repeats its shortfall, a string that underperforms every winter. Patterns like that are what turn a report from a receipt into a management tool.

Uptime, downtime, and lost generation

The second thing a report should show is how much of the period the system was actually working. That is uptime, and it is not the same as production. A system can produce a respectable total while spending days offline, if the days it worked were sunny ones. Uptime is the share of the period the system was available and producing as it should, and downtime is the rest, with each downtime event named and dated.

Lost generation belongs next to downtime, stated plainly: how much electricity the system did not produce while it was down or underperforming, as far as the data allows it to be estimated. For owners whose systems earn Solar Renewable Energy Certificates, that figure has a direct financial meaning, because SRECs are earned on actual generation, and generation lost during a fault cannot be recreated afterwards. A report that hides lost generation inside a monthly total is not protecting the owner from bad news; it is delaying it.

Which alerts fired, and why

The third thing is the alert record: every alert the system raised in the period, what triggered it, and what happened next. An alert that fired and was checked is a closed item. An alert that fired, was never looked at, and then cleared itself is an open question, and it should be shown as one.

This matters because alerts are the early warning system, and a report is the proof of whether that system was actually watched. Owners should be able to see, in one place, whether an alert led to an inspection, a repair, or a decision that no action was needed, and who made that call. Without that, the same alert can fire month after month while nobody owns it.

What is missing from the data

The fourth thing is the one reports most often leave out: the gaps. If monitoring data is missing for part of the period, the report should say so, for which dates, and why, as far as is known. A gap is not a small detail. While data is missing, no remote check is possible, and a fault that starts during a gap will not be caught until the data returns or an owner notices something else. The earlier post on this site about missing monitoring data explains how a gap can quietly cost an owner revenue; a report that pretends the gap did not happen makes that worse, not better.

Uptime: what it means and how to read it

Uptime sounds simple, and it is often quoted as if it were. In practice, owners should read it carefully, because not every uptime figure means the same thing.

Uptime is not production

A system at 98% uptime can still have lost meaningful generation if the 2% it was down fell on the sunniest days of the month. Equally, a system can show a low production month with high uptime, which usually points to weather or shading rather than a fault. The two figures answer different questions: uptime asks whether the system was working, production asks how much it made. A report that gives only one of them is answering only half the question.

Owners should also ask what counts as "up" in the figure they are shown. Does it count a string that is producing nothing while the rest of the system works? Does it count an inverter that is running but logging repeated faults? A clear report defines its terms, so the owner is not comparing one provider's uptime with another's on different definitions.

How lost generation is counted

When a report states lost generation, it should also say how that figure was reached. Usually it is an estimate: what the affected part of the system would have produced in that period, based on its own past performance and the performance of the rest of the system in the same conditions. That is a reasonable method, and it should be stated rather than hidden, so the owner knows it is an estimate and not a metered fact.

What matters is that the estimate exists at all. Without it, downtime is an abstract percentage, and an owner cannot judge whether a fault was a minor interruption or a serious loss. With it, the owner can decide how urgently a repair is worth pursuing, and can keep a dated record of exactly when the loss began and ended, which is what supports any later warranty or SREC discussion.

Alerts: which ones matter and which ones are noise

Not every alert deserves the same response, and a monitoring setup that treats them all alike will either cry wolf or go quiet at the wrong moment. The difference between a useful alert system and a noisy one is usually the thresholds, not the technology.

Performance-change alerts

The most valuable alerts are the quiet ones: a string producing less than its neighbours, output drifting below its own past pattern, a day's production that does not match the weather. These are performance-change alerts, and they are the ones that catch problems early, before a fault becomes a failure. They work by comparing the system with itself, which is why they need history to be useful; a system with no baseline has nothing to compare against, and its alerts will be guesses.

Owners should ask whether their monitoring can raise this kind of alert at all. Some systems only report totals, and totals do not catch a slow drift. The monitoring-services post on this site explains what production monitoring covers; the alert question is the next one to ask about the same service.

Fault and offline alerts

The second group is louder and simpler: an inverter offline, a string at zero, a communications device that has stopped reporting. These should arrive promptly, because each hour of delay is an hour of generation that may be lost, and because some of them, such as a protection device tripping repeatedly, need prompt on-site assessment by qualified personnel rather than a wait-and-see response.

Here the question for the owner is not whether the alert exists, but where it goes. An alert that only appears inside an app nobody opens is not an alert in any practical sense. An alert that reaches the owner, or the person responsible for watching the system, by a route they actually check, is the one that gets acted on.

Setting thresholds so alerts stay useful

An alert system with thresholds set too tight will fire constantly, and owners learn to ignore it. One set too loose will stay silent while a real fault develops. Getting this right is a matter of judgement, not a factory setting: thresholds should be set from the system's own data, reviewed after the first few months, and adjusted when the system changes, for example after a repair or an addition.

A report can help here too. If the same alert fires every month and is always dismissed, the threshold is wrong, not the system. That is a finding the report should surface, so the threshold gets fixed instead of the alert getting ignored.

Monitoring subscriptions: what owners actually get

Many owners receive monitoring through a subscription, and the value of that subscription is decided by what it actually includes, not by the fact that monitoring exists. Before agreeing to one, or renewing one, an owner should be able to answer four questions about it.

First, what is watched, and how often? Continuous monitoring with regular reporting is a different service from a dashboard the owner must remember to open. Second, what reports arrive, and in what form? A monthly report with the four elements above is a different service from a live total with no record. Third, who acts on an alert, and how quickly? A subscription that only notifies the owner leaves the response to the owner; one that includes review and coordination, as SAMS provides, leaves the owner with a decision rather than a task. Fourth, what happens to the data? An owner should be able to keep their own history, so that a change of provider does not erase the baseline their alerts depend on.

No price can be quoted for any of this in a guide, because subscription terms vary by provider and by what is included. The comparison that matters is like for like: the same reporting, the same alert handling, the same data history, and then the terms that go with them.

The benefit owners are really buying is early problem detection. A fault caught in its first week costs less generation, and usually less repair work, than the same fault caught in its second month. That is the whole case for a subscription that watches and reports properly: not the dashboard, but the weeks it saves.

Which monitoring systems can alert homeowners to performance changes?

This is the question owners ask most often, and it deserves a careful answer, because no single product is the right answer for every system. What matters is whether the system in question can do five things.

It should measure at a level that can find a fault, not only at the level of the whole system. A fault in one string is invisible in a whole-system total, so monitoring that reports per string or per inverter is worth more than monitoring that reports only a single figure.

It should keep history, so that today's production can be compared with the same system's own past performance. Without history, there is no baseline, and without a baseline, a performance-change alert cannot be set honestly.

It should alert on change, not only on failure. A system that only reports when something stops altogether will miss the slow drift that costs generation quietly for months.

It should reach the owner by a route the owner actually uses, whether that is an app notification, an email, or a message to the person responsible for the system. The best alert in the world is useless if it sits unread.

And it should keep reporting when something goes wrong with the monitoring itself, so that a communications failure is reported as a fault rather than appearing as a quiet, empty period in the data.

Owners comparing systems should ask for these five things by name, rather than accepting a general promise that the system "monitors" the panels. A named capability can be checked; a general promise cannot.

How often reports should arrive, and what to do with them

A report that arrives once a year is a history lesson. A report that arrives every month, in the same form, is a management routine. Monthly reporting is the usual rhythm, and it fits the way solar faults develop: slowly enough that a weekly report is often noise, and fast enough that a monthly report still catches a fault while it is young.

What the owner does with each report matters as much as receiving it. A short routine is enough: check production against expectation, check uptime and any lost generation, read the alert record, and note anything missing from the data. If all four are clean, the report takes minutes. If one is not, that is the item to follow up, with the report itself as the record of when the problem started.

Over a year, those monthly reports become the system's own file: its production history, its fault history, its repair history, and its SREC record, all dated. That file is what a future buyer of the property will want to see, what a warranty discussion will rest on, and what turns a collection of monthly emails into proof that the system was looked after.

A short checklist before choosing a monitoring service

An owner choosing or reviewing a monitoring service can use the questions in this post as a single checklist.

Does the report show production against expectation, uptime and lost generation, the alert record, and any gaps in the data? Does the system alert on performance change, not only on failure, and does the alert reach somebody who will act on it? Are thresholds set from the system's own data and reviewed, rather than left at a factory setting? Does the subscription include review and coordination, or only notification? And can the owner keep their own data history, so the baseline survives any change of provider?

An owner who can answer yes to those has a monitoring service that reports, alerts, and proves what it claims. An owner who cannot is paying for a dashboard, and a dashboard is not a report.

Key takeaways

Solar monitoring reports turn monitoring into management: production against expectation, uptime and lost generation, the alert record, and the gaps in the data, every month, in the same form.

Uptime and production answer different questions, and a report should give both, with lost generation stated plainly so the owner can judge what a fault actually cost.

Alerts are only useful if they catch performance change early, reach somebody who will act, and are set from the system's own data, with thresholds reviewed rather than left to cry wolf or stay silent.

Before choosing a monitoring service, ask what it reports, what it alerts on, who acts, and whether the owner keeps their own history. Those answers, not a dashboard, are what the subscription is worth.

SAMS, Solar Asset Management Services, Washington, DC, provides SREC brokerage, production monitoring, maintenance and repair coordination, and inspections. Website: samsmd.com | Phone: +1 240-320-6468.