The Monitoring Failure
The ground faults themselves are a hardware problem — equipment fails. What makes this situation extraordinary is that Sunrun's "professional-grade monitoring," marketed on Page 1 of the Agreement, failed to detect or report 237 ground fault events spanning two full years. On every single one of those days, while the inverter was shutting down at midday and my system was generating zero power for the rest of the afternoon, Sunrun's monitoring system reported one thing: System Normal.
"System Normal" vs. Reality
The screenshot below is from the My Sunrun mobile app on March 28, 2026 — the single worst ground fault event in the entire dataset. The system shut off at 9:45 AM, producing only 2.9 kWh for the entire day (compared to an expected 22+ kWh). The app's verdict? System normal.
Notice one other detail in the app: it reports 23 panels. My system has 17 panels. Even the basic hardware inventory in Sunrun's own monitoring system is wrong.
What Sunrun's own production data actually recorded:
This is the fundamental contradiction at the heart of the monitoring failure. Sunrun collects 15-minute interval production data from my system — the same data I used to detect and document every one of the 237 fault events. They have every data point. The ground fault signature is unmistakable in their own data: normal production in the morning, then an abrupt cliff to zero, hours before sunset. The app screenshot and the production data come from the same company. One says everything is fine. The other screams that it is not.
The Customer Service Timeline
What happened after I discovered the problem and reported it to Sunrun tells its own story. Pay particular attention to what the production data shows during each phase of Sunrun's response.
Feb 26 — shutoff 11:45 AM — 7.4 kWh lost
Feb 27 — shutoff 12:00 PM — 11.2 kWh lost
Feb 28 — shutoff 12:00 PM — 10.2 kWh lost
Mar 1 — shutoff 1:00 PM — 9.4 kWh lost
Mar 2 — shutoff 12:30 PM — 11.1 kWh lost
Every single day of Sunrun's "investigation," the system was faulting. If anyone had looked at the production data — the data Sunrun was actively collecting in real time — the problem would have been immediately obvious. No one looked.
During this period of total silence from Sunrun, the system recorded 18 additional ground fault events. This included the three worst days of the entire month: March 25 (shutoff at 10:30 AM, 17.5 kWh lost), March 26 (shutoff at 11:15 AM, 15.3 kWh lost), and March 28 (shutoff at 9:45 AM, 19.4 kWh lost — the single worst event in the entire two-year dataset).
Read that carefully. The same monitoring system that showed "System normal" through 237 ground faults over two years has now, a month after I reported the problem myself, suddenly "detected" an issue. Their monitoring system did not detect anything — I did. March 2026 produced 22 ground fault events, the worst single month in the entire dataset.
What Sunrun Sees vs. What the Data Shows
To appreciate the absurdity of reporting "System normal" on a day with a ground fault, consider what the two data sources look like side by side for March 28, 2026 — the day I captured the app screenshot above:
Sunrun's Customer-Facing View
Sunrun's Own Production Data
Software Problem, or Management Problem?
Sunrun collects 15-minute production data from every system they monitor. The ground fault signature is one of the most trivially detectable anomalies in time-series data: normal production in the morning, then an abrupt cliff to zero, well before sunset. A simple rule — if production > threshold then drops to zero before sunset, flag it — would catch every single event. Any undergraduate computer science student could write the detection logic in an afternoon.
So the question becomes: does Sunrun's monitoring software genuinely fail to detect these events, or does it detect them and simply choose not to act? Both scenarios are troubling, and the data points toward the latter. Consider:
- Sunrun has the data. Their API returns the same 15-minute interval production readings that I used to identify every fault. The cliff-to-zero pattern is unmistakable.
- The scale suggests a management decision. With over one million residential customers[1], even a low false-positive rate at the individual system level could generate thousands of alerts per day fleet-wide. It is entirely plausible that Sunrun has tuned their alert thresholds to suppress anomalies rather than investigate them — prioritizing operational efficiency over individual customer outcomes.
- The timeline confirms it. After I reported the problem myself, Sunrun declared it "resolved" five days later without any investigation, while 6 consecutive faults occurred during that exact period. Then three weeks of silence while 18 more faults accumulated. This is not a software detection failure — this is a customer service triage system that deprioritizes problems until the customer pushes hard enough.
Either way, the result is the same: I was paying for "professional-grade monitoring" that never monitored anything, and I had to reverse-engineer Sunrun's own API to discover that my solar system had been failing nearly every other day for two years.
A monitoring system that fails to detect 237 ground faults is not monitoring. A customer service process that declares a problem "resolved" while it is actively occurring is not service. And a month-long delay between a customer's report of a safety-relevant electrical fault and the first offer to send a technician is not professional-grade anything.
[1] Sunrun, Inc., "Sunrun Reports Fourth Quarter and Full Year 2025 Financial Results," February 26, 2026. investors.sunrun.com