Global Settings: Alerts Management

Which alerts fire, at what threshold and severity, after how long, and who is notified β€” the highest-leverage page in Settings.

What this page is for

Alerts Management is where you decide what the platform tells you about. Every alert you have ever received traces back to a rule configured here: which condition is watched, how bad it has to be, how long it has to persist, how serious it is called, and who hears about it.

It is the highest-leverage page in Settings, and the one most worth revisiting. Too loose and real faults sit unnoticed inside the noise; too tight and the team stops reading alerts at all.

The Alerts Management page on the General tab: the searchable list of alert codes on the left and the selected alert’s escalation rules on the right.

Layout

Three tabs across the top group the alert catalogue by domain:

  • General β€” generation, communication, inverters, strings, meters, sensors, trackers, grid quality, EV chargers and invoicing. Around thirty codes.
  • Performance β€” performance ratio, adjusted PR, PR-temperature, availability, their relative equivalents, and tracker angle deviation.
  • Storage β€” the battery catalogue, by far the largest: BMS and PCS faults, cell voltage and temperature, insulation, fire and emergency stop, plus vendor-specific codes for Contel, Sungrow, Kstar, Jinko and Tesla.

Within each tab, the left column lists the alert codes with a Search alert codes… box above them. Selecting one opens its configuration on the right, headed by the human-readable name and the machine code underneath β€” for example Inverter Performance and INVERTER_LOW_PERFORMANCE. Quote that machine code when raising a support question; it is unambiguous.

Escalation Rules

Each alert has a Default Rule and can have additional rules beneath it. This is what makes escalation possible: the same condition can be minor for four hours and serious after twelve, notifying different people at each stage.

Each rule has an Active toggle, and every rule except the default can be renamed and deleted.

Field

What it does

Display Description

The text shown on the alert itself. Use it to say what to do, not just what happened.

Threshold

A comparison (Below, Above) and a percentage. The point at which the condition counts as breached.

Severity

How serious the alert is called, for example High. Drives sorting and prioritisation in the alert lists.

Alert After (Hours)

How long the condition must persist before the alert is raised. 0 means immediately.

SLA and SLA Units

The response time expected once the alert is open, in hours or days. Used to flag overdue alerts.

Notification Recipients

Who is notified. Leave empty and the alert still appears in the portal but nobody is emailed.

There is also an Internal checkbox at the top right of the alert. Internal alerts are kept for enSights use and are not surfaced to customers.

The Performance tab of Alerts Management, showing performance-ratio and availability alert codes and the Relative PR rule with its threshold, severity, delay, SLA and recipients.

How to add an escalation step

  1. Select the alert code in the left list.
  2. Press Add Rule.
  3. Name the rule, then set its threshold, severity, delay, SLA and recipients.
  4. Check the Active toggle is on.
  5. Press Update at the bottom of the page.

A common shape: the default rule fires at a mild threshold with a long delay and notifies the monitoring team; a second rule fires at a worse threshold with a shorter delay and notifies the account manager as well.

Excluded Systems

At the bottom of each alert is a collapsible Excluded Systems section with a count, listing sites for which this alert has been suppressed. Each row has a Restore link, and Restore All clears the list.

Exclusions are how a known, accepted condition at one site stops generating alerts without weakening the rule for everyone else β€” a site awaiting a part, or one whose sensor is known bad. Review the list periodically: an exclusion added during an incident and never removed is a fault you have permanently agreed not to see.

How to tune a noisy alert

  1. Find the code in the left list β€” search by name or by machine code.
  2. Look at Alert After (Hours) first. Raising it filters transient conditions without hiding real ones, and is usually a better first move than moving the threshold.
  3. If the alert is genuinely mis-scoped, adjust the Threshold.
  4. If only a handful of sites are responsible, exclude those sites rather than changing the rule.
  5. Press Update, then watch the next day or two before changing anything else.

The Storage tab of Alerts Management, showing the battery alert catalogue and the selected alert marked Internal, with its Excluded Systems section below.

Notes

  • Changes are account-wide and apply from the next evaluation. Alerts already open are not re-evaluated.
  • Turning a rule inactive is reversible and leaves the configuration intact β€” prefer it to deleting a rule you may want back.
  • An alert with no recipients still appears in the portal. Silence is not the same as absence.
  • Change one rule at a time. Loosening several thresholds at once makes it impossible to tell which change caused the flood.
  • Vendor-specific storage codes only fire on hardware from that vendor β€” the Contel, Sungrow, Kstar, Jinko and Tesla families are irrelevant if you run none of them.