1. Home
  2. Modules
  3. Alarms

Module M-03 · Alarms

Alarms on any machine metric - before drift becomes downtime.

You write the rule; Mavex watches the live value on every machine of that model and notifies the right people - email, SMS or in-app - the moment it holds long enough to matter. Every fire and every clear stays on the machine's record.

Request a Demo What the machine sends

AlarmsAll machine models demo data

Mavex portal screenshot: the alarm list - eight rules with their machine model, metric, trigger predicate, severity and how long it must hold - every rule readable on one line. Demo data.
Demo installation - illustrative data Eight rules on one screen. Each one names its metric, its trigger and how long the condition has to hold before anyone is told.

Rules, not black boxes

You set the rule. Mavex watches the metric.

Every alarm in Mavex is a rule you can read on one line: a metric, a trigger, a duration, a severity, a list of recipients. There is no opaque model deciding what counts as abnormal. The maintenance knowledge of the people who built the machine is written into the rule - and the rule runs on every machine of that model, at every customer, from the day you save it.

That is what predictive means here: drift is caught while it is still drift - a motor drawing more current week after week, a power draw that no longer matches its own ten-minute average, a pressure that leaves its band.

Anatomy of a rule

Six things a rule knows

  • Model

    One rule, every machine of that model. Configure "haul-off motor over-current" once for the aftercooler model; every aftercooler you have shipped is watched.

  • Metric

    Any value the machine reports: current, speed, vibration, temperature, pressure, flow, power, a switch state, the machine state itself - anything in the model's metric list.

  • Trigger

    Four kinds. Single value - a switch is on. Threshold - above, below or outside a band. Deviation from average - differs from its rolling average by more than x%. Percentile - above the P95 of the last hour.

  • Clauses

    A rule can hold several metric-trigger pairs. "Process air valve below 39 OR water solenoid off" is one alarm, called Die feed interrupted.

  • Duration

    How long it must hold. 0 seconds fires on the first matching read; 120 seconds ignores a blip. The number the maintenance engineer would write on the checklist.

  • Severity & recipients

    Critical, Warning or Info, sent to users or to named notification groups - "service desk", "Plant B supervisors" - so one change propagates to every alarm that uses it. By email, SMS or in-app.

What happens when it fires

A notification to the right people, a record on the machine

  • Email, SMS or in-app

    To the selected users and groups, with the alarm name, the machine and the value that tripped it.

  • On the machine page

    The alarm shows its live status - Firing, Cleared · 8m, Never fired - next to the metrics it watches.

  • In its history

    Every fire and clear with timestamp and value, on a fired/cleared timeline you can zoom.

  • On the chart

    Overlaid on the metric in Explore, so the cause is visible next to the effect.

  • Versioned

    Every rule keeps its change history - what was active, and from when.

Two audiences

One alarm, two readers

  • Your customer's operator

    Sees the alarm in the branded portal with the name you gave it - Water-in pressure out of band - and the description you wrote: what it means, what to check.

  • Your service team

    Sees the same alarm across the fleet, opens the metric's history around the trip point, and diagnoses from live data instead of dispatching a technician.

From alarm to service

Maintenance you recommend, not repairs you rush

In the customer story, the service team spots wear and parameter drift early and recommends maintenance before failures - and the builder now bills its customers a subscription for the connected service. An alarm is the start of a service conversation you would otherwise have after the breakdown.

Measured results

What early alarms changed in the field

Outcomes measured across Mavex deployments with a plastic extrusion machine manufacturer.

  • −40% Unplanned downtime for your customers Delivered via branded portal - predictive alerts gave machine buyers visibility they never had before.
  • −58% On-site service visits Live machine metrics answered most first-response calls remotely.
  • +1 New revenue stream for builders The connected service became a subscription billed at the point of machine sale.

Results based on early customer deployments. Individual outcomes vary by industry, machine type, and operational context.

The full customer story and every figure

Common questions

Questions we hear about alarms

Is this predictive maintenance or condition-based alarms?
Condition-based rules on live metrics, configured by you. Mavex does not run an automatic anomaly-detection model. Deviation-from-average and percentile triggers catch the drift that precedes a failure - the predictive value most maintenance teams actually use.
How are people notified?
By email, SMS or in-app, to the users and notification groups on the rule. Alarm status and history are always visible on the machine page, whether or not anyone is notified.
Do we need extra sensors?
Rules run on the metrics the machine already reports. If a failure mode needs a signal the machine doesn't have, that is a hardware decision on your side - Mavex reads it once it is in the PLC.
Can our customers write their own rules?draft
Rules are managed by the manufacturer role - you write them, your customers read them. What a customer-role user can change is set per installation.

All questions, general and technical

Keep exploring

Other modules

Get in touch

Ready to connect the machines you build?

Tell us about your machines and your customers - we'll show you exactly what Mavex can do for your business.

Request a Demo Read the FAQ