Four kinds of alarm
| Category | What it means | First check |
|---|---|---|
| Communication failure | Data stopped arriving from a device; the device may still be generating | Is the meter still showing export? Is the whole block or logger offline? |
| Component down | Equipment has stopped: inverter trip, string or SCB fault, transformer outage | Confirm on site or via a neighbouring sensor, then dispatch |
| Underperformance | Equipment running, but below expected output | Compare with similar equipment under the same irradiance |
| Abnormal performance | Readings outside normal patterns: temperature, voltage, power factor | Check sensor health before assuming a fault |
In practice, communication failures are often the largest group by count, but rarely the largest by energy lost. Sort by energy, not by count.
Statuses that keep the queue honest
- Open: raised, not yet looked at.
- Acknowledged: someone owns it and is investigating.
- Wrong alert: a false positive. Track these: if a rule produces many, fix the rule.
- Closed: resolved, with a reason.
Measure response and resolution
Track both the mean and the maximum. A good mean can hide a handful of issues that sat open for two weeks, and those are usually the expensive ones.
240 active alerts: 170 communication failures, 35 underperformance, 29 component down, 6 abnormal performance. Mean resolution time 3 hours; maximum 15 days.
The headline count suggests a crisis, but most alerts are data issues. The 15-day maximum is the real problem: find out which alert it was and why it waited.
Avoid alarm floods
- Suppress solar generation alarms at night and in very low irradiance.
- Group alarms that share a root cause, such as every inverter behind one failed data logger.
- Add a short delay before raising transient alarms that clear themselves.
- Review the noisiest rules every month and retire or tune them.
From alert to ticket
Not every alert needs a ticket. A useful rule: raise a ticket when an alert needs someone to go and do something, and link the ticket back to the alert so the energy lost and the work done stay together. Tickets can be system-generated from rules, created from maintenance findings, or raised manually.
How nxtGrid helps
- Alerts dashboard with active alerts by component, status distribution and mean and maximum response and resolution times
- Alert categories for communication failure, component down, underperformance and abnormal performance, with open, acknowledged and wrong-alert statuses
- Tickets dashboard covering system-generated, maintenance and manual tickets through to closure
- Data availability monitoring to separate communication problems from real outages