Rules that fire on an event

Updated 29 Sep 2026

Most rules watch a reading and fire when it crosses a threshold. Some of the things worth reacting to aren't readings at all: a job finishing, a device dropping offline, a gateway coming back. Those are events, and a rule can fire on one directly.

Creating one

1. Open Rules → New rule.
2. Under Fire this rule when…, choose Something happens.
3. Pick the event.
4. Add actions exactly as you would on any other rule.

There's no tag, operator or threshold on an event rule — there's no reading to compare. The actions simply run each time the event happens.

What you can trigger on

Job triggers appear only if jobs are enabled on your account.

Narrowing a job trigger

A job trigger fires for any job by default. If you only care about one kind of run — say you want to POST a report when a drilling job finishes, but not a maintenance one — pick a Job type and the rule ignores the rest.

Narrowing to one device or gateway

A device or gateway trigger also fires for everything by default: a device goes offline means any device on the account. Pick a device or gateway and the rule watches only that one.

An unscoped rule is a perfectly good default. Each device has its own cooldown, so a rule that fires when your first till drops offline is still ready when the second and third go down — one alert each — while the same till flapping inside its window still produces one. The alert names the device that triggered it either way.

Scoping is worth it when different things deserve different handling: a scoped rule lets you send the freezer alarm to the kitchen and the till alarm to the shop manager, with a severity that matches.

The scope is only offered on device and gateway events — a job event isn't about a device, so pointing one at a device would create a rule that could never fire, and Synacl refuses rather than saving it.

You can create and edit these rules in the mobile app too: Automations → Rules → +, then choose Something happens. The same device, monitor or gateway picker is there, and saving from either the web or the app keeps the scope you picked.

What to do about it

Every action available to a threshold rule works here too: in-app, email, webhook, MQTT, a saved action, controlling an actuator, and starting or ending a job. A few combinations that come up often:

• A job finishes → webhook. The most common one. The webhook receives the job number, the job type and the machine, so your own system can pull the report and file it.
• A job finishes → control an actuator. Park a valve, kill a pump, sound a hooter.
• A gateway goes offline → email. You'll usually want a cooldown of an hour or so on this one; a gateway on a flaky link can flap.

The email names what happened and which device or gateway it happened to, so a device/offline alert is readable on a phone without opening the app.

The same permission rule as any other rule applies: controlling an actuator, running a macro, firing a saved action or starting/ending a job each need the matching permission to save or switch on — see who can do what in a rule.

Cooldown still applies

A cooldown stops a rule re-firing within the window you set, exactly as it does for a threshold rule. It's worth setting deliberately here: events can arrive in bursts, and a gateway reconnecting three times in a minute would otherwise send three emails.

The window is per device or gateway, not per rule. A rule watching every device keeps a separate cooldown for each one, so one device going down never silences another; the same device going down again inside its window is still one alert.

A gateway outage is one alert. When a gateway goes offline, every device behind it (and any sub-gateway forwarding through it) is marked offline with it. Those offlines share the gateway's cooldown, so a rule on a device goes offline, a gateway goes offline, or both sends one alert for the outage rather than one per device — if the rule watches gateways, the alert names the gateway; a rule that only watches devices names one of the devices behind it. A device that drops on its own while its gateway is up still alerts on its own.

One more case is handled for you. If a machine loses power mid-job and re-announces that job when it boots, the rule won't fire a second time for the same run — you get one webhook per job, not one per restart.

Starting and stopping jobs from a rule

The reverse also works: Start a job and End a job are action types, so a threshold or an event can open or close a run. A job normally starts from a switch on the machine; this is the option when the signal is a reading instead.

Both are safe to fire repeatedly, which matters because a condition like "spindle current above 40 A" stays true for a long stretch:

• Start a job joins the run already open on that machine instead of starting a second one.
• End a job does nothing when no run is open.

Related: Create an alerting rule · Severity and cooldown · Webhook actions