Alerts & Notifications

Alerts

Alert Manager ▸ Alerts lists the alerts your rules raised: what fires right now, the resolved ones, or both. Open in Mirox

Each alert shows its level, the rule, the plant, the component (for rules judged on each component), the value, and since when — or from when to when — it fired. An alert that arrived during a silence is marked Silenced.

An alert resolves by itself when the condition no longer holds, when the rule is switched off, changed so that it no longer matches, or deleted. Resolved alerts stay in the list as history.

Acknowledge tells your colleagues that someone is on it. It does not close the alert — only the plant's values do.

Rule and silence changes also appear in your organization's activity.

Who Is Notified

When an alert opens, everyone in your organization who has access to the plant is notified — in the app, by push on the mobile app and by email, exactly as each person chose in their own notification settings under the group Alert Manager. There everyone picks the channels and the minimum level from which they want to hear about these alerts; by default it is Normal.

When the alert resolves, the people who were notified receive a resolution notice. The notification links straight to the alert.

Silences

A silence keeps notifications away for a while — for maintenance, a known problem or a planned shutdown. Matching alerts still open and close and appear in the list, marked Silenced; only the notifications and receivers stay quiet.

Open Alert Manager ▸ Silences and click New silence. Open in Mirox Choose:

• Rule — one rule, or every rule.
• Plant — one plant, or every plant.
• Starts — now, or at a planned time.
• For — from 1 hour up to 1 year, or Until a date… for a free end date (at most one year after the start).
• Comment — why, so your colleagues know.

A silence ends by itself. Remove it earlier with its delete button. Silences are created and removed by Admins and Moderators.

Receivers

A receiver gets every alert of the rules it is attached to, automatically — a ticket system, a team channel or a shared mailbox. People do not need a receiver; they are notified through their own settings anyway.

Open Alert Manager ▸ Receivers and click New receiver Open in Mirox, then attach it to rules under Receivers in the rule editor. Send test delivers a sample alert so you can check the connection.

Email

A list of email addresses. Each alert and its resolution arrive as one email.

Webhook

An HTTPS address that receives a POST for each alert and its resolution, in one of these formats:

• JSON (signed) — the full alert as JSON, see below.
• Microsoft Teams, Slack, Discord — a ready-made message for an incoming webhook of that service. See Connect Microsoft Teams for how to create one.

When you create a webhook receiver, its signing secret is shown once. Every request carries the header X-Mirox-Signature: sha256=<hex> — the HMAC-SHA256 of the raw request body with that secret — plus X-Mirox-Timestamp and a unique X-Mirox-Delivery-Id. Check the signature before you trust a request, and use the delivery id to ignore a repeated delivery.

The JSON (signed) body:

{
  "version": "1",
  "status": "firing",
  "event_id": "1216448682925686786",
  "rule_uid": "A1B2C3D4E5F6",
  "rule_name": "Inverter without power",
  "rule_version": 3,
  "priority": "high",
  "park_uid": "0A1B2C3D4E5F",
  "park_name": "Plant North",
  "instance_key": "inverter_id=7",
  "labels": { "inverter_id": "7" },
  "component": "Inverter 7",
  "metric": "AC power per inverter",
  "value": 0.0,
  "unit": "W",
  "op": "lt",
  "threshold": 10.0,
  "condition_since": 1791200400,
  "title": "[FIRING] Inverter without power — Plant North (Inverter 7)",
  "body": "Inverter 7 delivers only 0 W (limit 10 W)",
  "link": "https://service.mirox.io/#/alertmanager?tab=alerts&alert=1216448682925686786",
  "sent_at": "2026-10-06T09:05:12+00:00"
}

status is firing or resolved; a resolution repeats the alert with the last value judged. condition_since is a Unix timestamp. Fields may be added in later versions — ignore what you do not know. event_id is a string — the id is longer than a JavaScript number can hold exactly.

After repeated failed deliveries a receiver is switched off and marked Disabled; check the address and create it again.

BWE outage interface

Reports the outages of your wind turbines to your direct marketer through the BWE outage interface. Every alert of a turbine becomes an outage: when the alert fires the outage begins, when it resolves the outage ends. Your direct marketer runs the interface and gives you three things: the web service address, the token address and the user name and password — enter them in the receiver. The password is stored encrypted and never shown again. Test sign-in signs in and shows how many plants the marketer has assigned to your account; it never reports an outage.

• Outage reason: one receiver per reason — MAINTENANCE (faults, maintenance, manual operation), ADMINISTRATIVE (administrative orders such as noise, bat or bird protection), GRID (curtailment by the grid operator) or MARKET (curtailment by the trader). Use GRID and MARKET only when the source of the curtailment is certain.
• Remaining capacity reported: 0 kW (a full outage) or the alert value when the rule watches a power metric — never more than the installed capacity the marketer has on file.
• Reported ahead: the interface needs an end time, so an open alert is reported up to this many days ahead (30 by default); its resolution cuts the outage back to when it really ended.

Each turbine is found in the marketer's own plant list by its serial number from the turbine master data; the manufacturer settles a shared serial number. Attach the receiver to rules that watch turbines one by one — the examples Turbine down by a fault and Turbine curtailed for the environment are made for it. A turbine the marketer does not know is shown as a failed delivery of the receiver.

Templates

A template designs exactly what a receiver sends, so any system gets the format it expects: for a webhook the method (POST, PUT or PATCH), your own headers and the body in JSON, XML, CSV, HTML, plain text or form data; for an email the subject and the text (plain text or your own HTML). You write fixed text and insert variables of the alert, the rule, the plant and the component. A template is reusable: several receivers can use the same one, and a change applies to all of them at once.

Open Alert Manager ▸ Receivers Open in Mirox: below the receivers you find your Templates and the examples to start from. Use example copies one into your organization; New template starts empty. The template opens in the builder: on the left the settings, the headers and the body, in the middle the list of variables — a click inserts the variable at the cursor — and on the right the live preview: the request or email exactly as it would be sent, with the sample alert or one of your recent alerts, and every error or warning. Then choose the template for a receiver — when creating it, or with the template button in its row. Without a template, a receiver keeps its built-in format.

Templates are created and changed by Admins and Moderators; every member can view them. A template that a receiver uses cannot be deleted — choose another one for that receiver first.

The template language

Inside a list section, {{@index}} (from 0), {{@number}} (from 1), {{@first}} and {{@last}} are available — for example {{^@last}},{{/@last}} puts a comma between items. A variable that does not exist stays empty, and the preview lists it as a warning. Nothing in a template is executed; it only ever produces text.

Variables

Dates are shown in the plant's time zone unless the date filter names another one. The plant has no field for a MaStR number or a market location — write such identifiers into the template as fixed text.

Filters follow the variable after | and can be chained, for example {{alert.value|kw|number:1:de}}:

Formats and escaping

The format of a template decides how a value is inserted, so a plant name with quotes or an ampersand never breaks the result:

• JSON — inside a string ("plant": "{{plant.name}}") a value is escaped as text; outside one ("value": {{alert.value}}) it becomes a JSON value: a number stays a number, text gets quotes, an empty value becomes null, objects and lists are written as JSON.
• XML and HTML — <, >, & and quotes are escaped.
• CSV — a field is put in quotes when it contains the separator, a quote or a line break; in a field the template already quotes, quotes are doubled. The separator is the one your template uses (comma, semicolon, tab).
• Form data — values are URL-encoded.
• Plain text — as it is.

Header values and the email subject never contain a line break. A template is checked when you save it: it must be complete (every section closed, every filter known), at most 64 KiB, and its result for the sample alert must be valid JSON or well-formed XML for those formats. Headers: at most 30, the names of standard headers only. Content-Type follows the format, and Content-Length, Host and the X-Mirox-* headers are set by Mirox — you cannot override them. Every webhook request remains signed: X-Mirox-Signature is the HMAC-SHA256 of exactly the body your template produced.

Examples

Each example is a starting point you copy and adapt:

• Generic JSON (signed envelope) — The documented Mirox alert envelope — a base for ticket systems and automation.
• Microsoft Teams card — An Adaptive Card for a Teams Workflows webhook, with plant, component and value.
• Slack message — Block Kit message for a Slack incoming webhook, with a button to the alert.
• Discord embed — A coloured embed for a Discord channel webhook (red firing, green resolved).
• XML document — The alert as an XML document, for systems that expect XML.
• CSV row — A header and one data row per alert, comma separated.
• Plain-text email — A compact plain-text email with the key facts, in the Mirox email frame.
• HTML email — Your own HTML email with a fact table — sent exactly as designed.
• Direct marketer: reduced availability (CSV) — German notice of reduced plant availability as a semicolon CSV — a starting point to adapt to your direct marketer's specification.
• Direct marketer: reduced availability (email) — German email notice with plant, start, end and available power — edit it to match what your direct marketer requires.

The direct marketer examples (in German) report a reduced availability of a plant: plant name and id, start and end, installed power and — for a rule on a power metric — the available power, once as a CSV row with semicolons and once as an email. There is no binding format for this notice; adapt the columns and the wording to what your direct marketer requires and fill in the MaStR number and the market location as fixed text.

A template for a ticket system that expects XML:

<ticket priority="{{alert.level}}">
  <title>{{alert.title}}</title>
  <site id="{{plant.uid}}">{{plant.name}}</site>
  {{#component.name}}<asset>{{component.name}}</asset>{{/component.name}}
  <opened>{{alert.since|date:"iso"}}</opened>
  <link>{{alert.link}}</link>
</ticket>

Test Your Alerting

A test run shows the whole path of an alert on one of your plants — without waiting for a real problem and without touching the plant's own data. Open Alert Manager ▸ Overview and click Test alerting Open in Mirox, then choose the plant, the level the test alert should have (up to Critical) and, optionally, receivers.

The platform then writes a scripted test signal for that plant: quiet for 5 minutes, over its threshold for 15 minutes, quiet again. The plant's agent evaluates it like any of your rules, so:

1. about 5–10 minutes after the start the test alert opens — at the level you chose;
2. everyone who would be notified about a real alert of that level on that plant is notified — in the app, by push and by email, according to their own settings — and the chosen receivers get it too;
3. about 15 minutes later it resolves by itself, with its resolution notice.

The page follows the run step by step. A run ends by itself after about 30 minutes, or earlier with Stop; its alert stays in the history. Test runs never appear among your rules, and test data is only written while a run is active. Admins and Moderators start test runs; up to three may run at the same time.

Related

• Alert Manager overview
• Alert Rules
• Notification Settings