Proving a solar warranty claim with monitoring data comes down to three things that all have to exist before the fault appears: a baseline of what the system was designed to produce, a continuous record of what it actually produced, and a fault log with dates on it. Claims rarely fail because the system was healthy. They fail on access — because in a great many South African homes the monitoring account was opened in the installer's name, on the installer's email address, and the owner only discovers that on the day they need the history.
I was on the driveway with a coffee going cold when mine was set up. The installer had the inverter serial number in one hand and his phone in the other, tapping through the setup screen to link the dongle to the portal. It took about ninety seconds. He said the system was live and that I'd see everything in the app, and then he drove off, and I went inside and looked at the app he'd put on my phone, which showed a green arc and a number in kilowatts, and I felt the particular satisfaction of a man whose machine is working.
What I did not look at was the account. The email address in the profile was his. He had created the site under his own login so he could support all his customers from one dashboard, which is how it is usually done and not remotely malicious. It just meant that the entity holding the history of my roof was a small company in another province whose WhatsApp number would eventually stop answering.
Two winters later the yield line started to sag, and I had nothing to compare it to.
The baseline is a commissioning-day document, not a feeling
The most useful number in any warranty argument is the one recorded on the day the system was switched on. Ask for it while the bakkie is still in the driveway, because that is the only hour in the entire life of the system when you have leverage.
What I want in my hand at handover is the design simulation the installer used to size the array — the expected annual yield figure and the month-by-month breakdown that came out of it — plus the commissioning sheet with the measured values on the day, the string layout as built, and the Certificate of Compliance. That simulation is usually the only written statement of what the system was supposed to do. Without it, "underperforming" is an opinion.
The design figure also tells you what normal looks like across the year, which matters more here than in most places. A Cape Town array in June and a Gauteng array in June are not the same conversation, and a Highveld system in a hailstorm week is not evidence of anything. When I finally did get a claim going, the first thing the assessor asked was whether the shortfall held up after the seasonal correction. If you have the monthly expected figures, you can answer that in one table. If you don't, you spend three weeks arguing about clouds.
Get the history out of the platform and into a folder
A dashboard is not a record. A dashboard is a window someone else can close.
My habit now, on the first Sunday of every month, is fifteen minutes at the kitchen table. Download the CSV of the month's data. Save the platform's own monthly PDF report if it produces one. Drop both into a folder named by year and month, in cloud storage that has nothing to do with the installer or the manufacturer. Take a screenshot of the dashboard on any day something looks odd, because a screenshot carries a date and survives a platform migration, a firmware change or an account deletion.
The raw export matters more than the pretty report, because the raw file has the intervals in it — the half-hourly or five-minute readings that let someone else re-plot the data if they dispute your graph. When I eventually asked for my history, the answer was that the site could be transferred but the backfill would only go as far as the day the transfer happened. Two years of data existed. I could not reach it.
If you are still at the buying stage, ask the question directly at handover: whose email address is the account under, can the site be transferred to me, and can I be added as a second administrator now rather than later. Get the answer in the handover pack in writing. Your consumption and generation data is your personal information, but that is a legal argument you do not want to be having in year four with a warranty clock running.
An alert is not a claim
This is the distinction that trips people up. A monitoring alert is a threshold someone else set — a battery temperature warning at 02:14, a communication failure, an insulation resistance flag. Most of them are the platform being cautious. A warranty claim trigger is a documented, sustained deviation from the baseline, over a defined period, that exceeds whatever tolerance the warranty document specifies.
I have had four alerts in as many years. None of them was a defect. What actually started the claim was a line on a graph that refused to come back up.
What a sag actually looks like
It is almost never dramatic. There is no red banner. The morning ramp is slower and the afternoon shoulder is lower, and the monthly total sits some percentage under the same month a year earlier — say eleven percent, on a comparison of two clear months. Eleven percent means nothing in a cloudy week. It means a lot when the weather was comparable, which is exactly why you need last year's file.
Three patterns are worth recognising and then handing over, not chasing yourself. I don't go on the roof and I don't open the inverter; I note and I forward.
String mismatch
On a system with two strings, one string's current drifting steadily below the other's over weeks is a pattern, not a cloud. The value is not in my diagnosing it. The value is in the graph showing divergence that starts on a date, and that date going into the email.
Derating
An inverter that pulls its AC output back in the middle of a hot day, well below what the array is clearly capable of, is telling you something about its own temperature — a failed fan, a unit mounted on a west-facing garage wall that hits 45 °C by two in the afternoon. That shows up as a flat top on a curve that used to be round. Again: photograph the graph, note the ambient, send it.
Battery state of health moves slowly, which is the point
State of health is the number most likely to be argued about, because different platforms calculate it differently and a firmware update can move it five points without anything physical changing. That is why the trend matters and the single reading does not. What you want is the same metric, on the same platform, plotted over eighteen months, with the drop visible against your usage pattern and your cycling.
If the warranty says the battery is covered to a stated capacity retention after a stated number of cycles or years, then your evidence is that graph plus the cycle count from the platform, and it is worth pulling both on the same day so they line up.
The clause nobody reads: staying connected
Some manufacturer warranties make the performance guarantee conditional on the system staying connected to their monitoring platform for the warranty period. Not connected most of the time — connected, with a data record they can inspect. If the dongle dies in month nine and nobody notices until month twenty, that gap becomes the first question in the assessment, and it is uncomfortable to answer.
So the practical rule: a monitoring outage is not a minor inconvenience, it is a warranty risk. I treat a flat data line the same way I treat a leak — same day, phone the installer, keep the email.
Your municipal meter is the witness that belongs to you
Here is the thing I only understood late. The platform belongs to somebody else. The municipal bill belongs to you.
Your prepaid purchase history or your monthly municipal account is an independent record of how much electricity you were still buying from the grid. If you were spending one amount in the first year and a visibly larger amount in the third, with no new appliances and no change in the household, that is corroborating evidence that nobody can revoke your access to. It is crude. It is also yours, it is dated, and it sits outside the entire solar ecosystem.
Assembling it, and what it will not do
When I finally put the claim together, it was one page and four attachments. The page was a plain timeline: commissioning date, first date I noticed, what I did, who I contacted, what they said. The attachments were the design simulation, the monthly exports from the day of transfer onwards, the fault log, and the municipal purchase history.
The assessor's job is to process a lot of these. A dated, ordered, boring package does more for you than an angry paragraph ever will.
And the honest limit: monitoring data shows that something changed. It cannot show why. A module can underperform because of a manufacturing defect or because something hit it, and no graph settles that argument — a physical inspection does. There is also a real possibility that the shortfall sits inside the warranty tolerance and the claim goes nowhere, which is worth knowing before you spend three months on it. The data gets you to a fair conversation. It is not a guarantee of the outcome, and anyone who tells you otherwise has not been through one.
