Alarm pipelines

This page is for administrators. A notification pipeline makes the gateway call out to a webhook when an alarm changes state. How alarms themselves work is in Alarms.

What it does

The pipeline service listens to alarm changes the same way a connected screen does. For each alarm.active, alarm.acknowledged or alarm.cleared event it finds the enabled pipelines whose trigger matches and whose minimum severity the alarm meets, and posts the alarm to each pipeline's webhook. Each pipeline runs on its own, so a long wait on one does not hold the others back. The alarm engine never waits on a pipeline: a change is queued and everything else happens afterwards.

A shelved alarm is deliberately silenced: its lifecycle keeps recording, but no pipeline is told until the shelf comes off.

The Pipelines page

Open Alarms, then Pipelines (the entry appears only for administrators). The page is titled Notification pipelines. It lists pipelines with Name, Send when, Severity, Wait, Address and State, with row actions to test and delete. Below the list, a table of recent sends shows Time, Pipeline, Alarm, Event, Result and Detail.

Creating a pipeline

1. Add a pipeline and give it a Name of up to 80 characters.
2. Choose Send when: when an alarm goes active, is acknowledged, or cleared. One pipeline has one trigger; make three pipelines for all three.
3. Choose the Lowest severity: Any severity, or a level. Alarms whose severity (1 to 1000) is below it are ignored.
4. Optionally set a wait in seconds (0 to 3600). See below.
5. Enter the Address: a full http:// or https:// URL, up to 500 characters.
6. Save. New pipelines are enabled; a disabled pipeline matches nothing.

The wait

A wait means "tell me if it is still a problem". The pipeline sleeps for the given seconds and then, for the active trigger only, reads the alarm again: if it is no longer active (it cleared or was acknowledged meanwhile), nothing is sent and the log records skipped with "The alarm was no longer active after the delay." For the acknowledged and cleared triggers the wait only delays the send.

Testing

The test action posts a made-up alarm (Test alarm on Test.Tag, severity 500, state active, value 1) to the address with "test": true, using the pipeline's own trigger as the event, and records the result in the log.

Payload

Each send is one POST with Content-Type: application/json and User-Agent: Scadex-Gateway:

{
  "event": "alarm.active",
  "test": false,
  "pipeline": "Night shift pager",
  "sentAt": "2026-11-08T12:00:05.123Z",
  "alarm": {
    "id": "…",
    "name": "High temperature",
    "tagPath": "Line1.Oven.Temp",
    "severity": 800,
    "state": "active",
    "value": 231.4
  }
}

event is alarm.active, alarm.acknowledged or alarm.cleared. alarm is the alarm exactly as the matching /sync frame carries it, so it has every field the frame has: the alarm's id, name, tag path, severity, state, the value that changed it, occurrenceId, and acknowledgedBy and acknowledgedByName on an acknowledgement. Alarms describes the frames. The test payload above shows only the six fields the test sends.

Any 2xx answer counts as sent. Anything else, no answer within 10 seconds, or a connection error, counts as failed with the reason in the detail.

The log of sends

Every attempt is written to the database: time, pipeline, alarm name, tag path, event, result (sent, failed or skipped) and a detail of up to 300 characters. The gateway keeps the last 500 rows and deletes older ones as new ones arrive. Unlike event streams, this log survives a restart.

Limits

• One step per pipeline: a trigger, a severity floor, an optional wait, a webhook. No escalation chains, schedules, rosters or on-call calendars.
• No retries. A failed send is logged and forgotten.
• Webhook only: no email, SMS or voice. Put a service that does those behind the webhook.
• No authentication header or signing on the request.
• Changes queue in memory (1,000 deep, oldest dropped under a burst); a change still queued when the gateway stops is not sent.

See Alarm to webhook for a worked example.

API

All routes need the admin role. The full reference is in Admin API.

Route	Purpose
GET /api/v1/admin/alarm-pipelines	List pipelines
POST /api/v1/admin/alarm-pipelines	Create {name, enabled?, trigger, minSeverity?, delaySeconds?, webhookUrl}; trigger is active, acknowledged or cleared; minSeverity 0 to 1000 (default 0); delaySeconds 0 to 3600 (default 0)
PUT /api/v1/admin/alarm-pipelines/{id}	Replace the same fields
DELETE /api/v1/admin/alarm-pipelines/{id}	Delete
POST /api/v1/admin/alarm-pipelines/{id}/test	Send a test alarm: {status, detail}
GET /api/v1/admin/alarm-pipelines/deliveries?limit=	The log, newest first, up to 500