An automation isn't firing

Work through the items in order; each is a distinct reason an automation fails to fire even when the event is visible in the Dashboard’s Live feed.

1. Automation is disabled

Check: If the automation’s Enabled toggle is off, it’s skipped entirely — no conditions are evaluated for it.

Fix: Turn Enabled on.

2. Conditions do not match

Open the automation’s If panel and compare each condition against the event as the Dashboard’s Live feed shows it: the Event column names the player and carries values such as the chat message or weapon. The Live feed does not print field names; those are listed in Event types.

Case sensitivity

Operator	Case sensitive?
`equals` (`$eq`)	Yes — `Admin` ≠ `admin`
`not equals` (`$ne`)	Yes
`contains` (`$contains`)	No — comparison is lowercased on both sides
`not contains` (`$ncontains`)	No
`regex` (`$regex`)	No — compiled with the `iu` flags (case-insensitive, unicode)

If you are using equals to match a player name or chat channel, make sure the value matches the exact casing that Squad writes to the log.

Wrong field name

Event fields come directly from the parsed log line. The field names are fixed per event type. A condition naming a field the event type doesn’t carry is treated as not resolved: the automation does not fire on that event, whatever the operator (including $ne, $ncontains, $lacks). Inside an OR-group such a rule is skipped instead: the group still passes when another rule in it matches.

Fix: Check the field names for the event type in Event types.

OR group behavior

Conditions at the top level are combined with AND — every condition must match. If you need “A or B”, put both as leaves inside a single OR group. A mix of top-level conditions and an OR group means all top-level conditions AND at least one leaf in the OR group must match.

Regex not compiling

Patterns longer than 256 characters or containing nested unbounded quantifiers (e.g. (a+)+) are refused when you save the automation. One that is already stored is treated as non-matching and does not throw an error.

Fix: Simplify the pattern.

3. The pause is holding the automation back

Check the automation’s Pause row — “stay silent for N sec after a run, per …”. It can hold a automation back even when its conditions match:

Stay silent for N sec — after the automation runs, it won’t run again until N seconds have passed.
per — set to either Whole automation (one shared pause for everyone) or Per player (a separate pause per player’s EOS ID; an event with no player, or no EOS ID, shares the automation-wide pause).

A pause of 0 sec means no pause at all — if you set that and the automation still isn’t firing, the pause isn’t your problem.

Fix: Lower the pause, or wait it out. See Pause an automation.

4. Wrong surface — automation not scoped to this server

Automations belong to your organization, not to one server, but each can be narrowed to specific servers. An event on server A will not fire an automation scoped only to server B. An automation set to All servers fires on every server in the organization, including ones added later.

An empty Servers selection is not “all”. It is a scope that was deliberately emptied, it matches nothing, and such an automation never runs anywhere.

Check: Open the automation and verify the Servers selection either includes the server where the event occurred or is set to All servers, and is not empty.

Fix: Add the server to the automation’s scope, or pick All servers.

5. Manual automation: member is not allowed to run it

There is no automation:exec:<id> permission key in Settings → Roles — don’t go looking for one. A manual automation is run from the Actions dropdown — on the server status panel, or on a player’s card — and it appears there for either of two reasons: the member’s role holds Automations → Update, which opens every manual automation, or the member’s role is linked to that one automation through the Automation actions rows. Owner and Admin hold the key and run everything.

Symptom: The automation is missing from that member’s Actions dropdown.

Fix: Either move the member to Admin, which holds Automations → Update and runs every manual automation, or give them a custom role. Both matrix routes — checking Automations → Update, or checking the box where a role’s column meets that automation’s row under Automation actions — apply only to a custom role, because system role columns are locked; assign that role to the member from the role selector in the Members table or in the invite dialog. See Grant per-automation execution rights and Roles and permission keys.

6. Manual automation: disabled, or not a Manual automation

The Actions dropdown — on the server status panel, and on a player’s card — lists only manual automations that are enabled and in scope for that server. An automation that is disabled, or whose kind isn’t Manual, simply isn’t in the list: there is nothing to click, and no error to read.

Fix: Find the automation in the Automations table, confirm its kind is Manual, and turn its Enabled toggle on.

7. An action inside the automation is failing

For event and scheduled automations, if one action in the list fails partway through — an RCON command with no live RCON connection, a fetch that times out — heliana doesn’t stop the rest of the automation’s actions, and it doesn’t retry the failed one. The automation still counts as having fired.

Action failures are not written to the Audit Log — that log records what moderators do, not what automation does. The only record of a run, including which actions in it failed and why, is the automation’s own Run history.

Fix: In the Automations list, open the row’s menu (⋮) in its Actions column, choose History, and check the Run history for the failed action and its error message, then check that action’s prerequisites. For RCON actions, check the RCON dot in the channel list under the summary pill in the server’s header on the Dashboard. For fetch actions, confirm the URL is correct and that the endpoint answers within 30 seconds.