When a SCADA alarm fires, the operators on the HMI see it immediately, but the tools that actually run the response - the ticketing system, the on-call paging tool, the maintenance queue - only find out if something tells them. A webhook alarm push is the mechanism that tells them, by sending the alarm event as an HTTP call to an external endpoint the instant the alarm occurs. This is more direct and more machine-readable than an email or an SMS, because it delivers a structured payload that another system can act on automatically. This guide covers the shape of that payload, how it feeds ticketing and on-call tools, how it differs from human notifications, and what it takes to deliver alarm events reliably and in order.
Webhook Alarm Push in one line: A webhook alarm push is the delivery of a SCADA alarm event to an external HTTP endpoint the moment the alarm changes state, by having the SCADA system POST a structured payload to a URL the consumer registered. The payload typically carries the tag or source, the alarm priority, the new state, a timestamp, and acknowledgement status, so the receiving system can create a ticket, page an on-call engineer, or update a queue without a human retyping anything. It differs from email or SMS notification because it targets a machine rather than a person and is meant to be parsed and acted on programmatically, which is why delivery reliability, retry on failure, and ordering matter.
The heart of a webhook alarm push is the payload, a compact structured message - usually JSON - describing exactly what happened. At minimum it identifies the alarm source, meaning the tag or asset the alarm belongs to, so the receiver knows what is in trouble. It carries the alarm priority or severity, so the receiver can decide whether this warrants waking someone up or merely logging a ticket. It carries the alarm state, distinguishing an alarm that has just become active from one that has returned to normal or been acknowledged, because a downstream tool needs to know whether it is opening an incident or closing one. And it carries a timestamp of when the state change occurred at the source, not when the message was sent, so the record is accurate even if delivery was delayed.
Beyond those essentials, a useful alarm payload includes context that saves the receiver from having to look anything up. That often means a human-readable description of the alarm, the value that triggered it and the limit it crossed, the area or site the source belongs to, and the acknowledgement status including who acknowledged it and when if it has been acknowledged. A stable unique identifier for the alarm occurrence is especially valuable, because it lets the receiver correlate the later return-to-normal or acknowledgement push with the original activation and avoid treating them as unrelated events. Without such an identifier, matching a clear to the alarm it clears becomes guesswork.
The state model carried in the payload is what makes the whole thing useful rather than just noisy. A single alarm typically goes through a lifecycle - it becomes active, it may be acknowledged, and it eventually returns to normal - and each of those transitions is worth a push so the external system can track the alarm's true status. A receiver that gets only the activation push, with no clear or acknowledgement, has no way to know the situation resolved and will leave a ticket open forever. Designing the payload and the set of pushes around the full alarm lifecycle, rather than just the initial trip, is what lets a ticketing or on-call tool stay in sync with reality.
The reason to push alarms as webhooks rather than only notifying humans is that a webhook lands in a system that can act on it automatically. A ticketing or maintenance tool receiving an alarm push can open a work item pre-filled with the asset, the priority, the description, and the timestamp, so there is a tracked record from the instant the alarm fired with no one transcribing anything. An on-call or incident tool receiving the same push can route the alarm to the right engineer based on its priority and the current on-call schedule, escalate if it is not acknowledged, and attach the alarm's clear push to close the incident automatically when the condition resolves. The webhook is the connective tissue that turns an alarm on a screen into a managed response.
This is a genuinely different thing from an email or SMS notification, even though all three can be triggered by the same alarm. An email or text is aimed at a person: it is prose, it is read by a human, and any action it prompts happens because that human decides to act. A webhook is aimed at a machine: it is structured data, it is parsed by software, and the action happens automatically according to rules the receiving system enforces. Email and SMS are excellent for getting a person's attention, but they do not create tickets, respect escalation policies, or close incidents on their own. A webhook can drive all of that, which is why serious integrations use webhooks for the automation and reserve email and SMS for the human touch.
In practice the two complement each other rather than competing. A well-designed alarm strategy might push a webhook to the ticketing system for every alarm so there is always a tracked record, push a webhook to the on-call tool for high-priority alarms so the paging and escalation logic runs, and separately send an SMS or email to a supervisor for awareness. Each channel does what it is best at. The webhook's distinct contribution is that it is the only one of the three that carries machine-actionable structure, so it is the channel that lets the response be automated instead of depending on someone reading a message and remembering to do something.
Because a webhook alarm push drives automated action, losing one is worse than losing a stray notification: a dropped activation means no ticket and no page, and a dropped clear means an incident that never closes. Reliable delivery therefore has to be designed in, not assumed. The core mechanism is acknowledgement and retry: the SCADA system considers a push delivered only when the receiver returns a success response, and if the receiver is unreachable or returns an error, the sender retries. Sensible retry uses a backoff so it does not hammer a struggling endpoint, and it gives up only after enough attempts that a brief outage on the receiver's side is comfortably ridden out rather than turning into lost alarms.
Retries make delivery robust but introduce duplicates, so the receiver has to be able to recognise a repeat. The standard defence is idempotency: each alarm push carries a unique event identifier, and the receiver treats a second arrival of the same identifier as a duplicate to ignore rather than a new event to act on. Without this, a retry after a receiver processed the first attempt but failed to acknowledge in time would create a second ticket for the same alarm. Pairing a stable event identifier on the sender with duplicate-suppression on the receiver is what lets a system retry aggressively enough to guarantee delivery without generating spurious duplicate actions.
Ordering is the third concern, because an alarm's activation, acknowledgement, and clear only make sense processed in sequence. If a clear arrived and was processed before the activation it clears, the receiver could close an incident it never opened, or reopen one that was already resolved. Preserving order can be handled by including a monotonic sequence number or a precise source timestamp on each push so the receiver can order events itself and hold or discard anything that arrives out of sequence. A cloud SCADA platform such as Merobix is well placed to provide all of this as a managed capability - firing the push at the moment of the state change, carrying a structured payload with a stable event identifier and source timestamp, and retrying on failure - so that field operations teams get alarms into their ticketing and on-call tools reliably without building the delivery, retry, and ordering machinery themselves.
At a minimum it identifies the alarm source or tag, the priority or severity, the new alarm state such as active, cleared, or acknowledged, and a timestamp of when the state change occurred at the source. Good payloads add context so the receiver does not have to look anything up: a description, the value and limit involved, the site or area, the acknowledgement details, and a stable unique identifier for the alarm occurrence. That identifier is important because it lets the receiver match a later clear or acknowledgement push to the original activation.
An email or SMS is aimed at a person: it is prose meant to be read, and any resulting action depends on a human deciding to act. A webhook is aimed at a machine: it delivers structured data that software parses and acts on automatically, such as opening a ticket, paging the right on-call engineer, or closing an incident when the alarm clears. The two are complementary, so many teams push webhooks to drive automated ticketing and paging while still sending email or SMS to get a person's attention.
A well-designed sender treats a push as delivered only when the receiver returns a success response, and if the endpoint is unreachable or returns an error it retries, usually with a backoff so it does not overwhelm a struggling endpoint. Retries let a brief receiver outage be ridden out without losing alarms, but they can produce duplicates, so each push should carry a unique event identifier and the receiver should ignore repeats. If retries are exhausted the event can still be lost, which is why a low-frequency reconciliation, such as periodically polling for any alarms the receiver did not record, is a common safeguard.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.