I have a no of custom scheduled tasks that have traditionally run via custom controller actions, triggered via a cron job in Azure. These tasks typically import and create content using data from external systems. I’m converting them into custom actions within Umbraco Automate as this seems a more logical place to run them. Question - am I correct in assuming any configured automations run on all instances in a load balanced env, therefore it’s down to my custom action code to ensure the tasks only run on the publisher?
Hi @Gavin5656
According to this:
- **Full audit trail**: Every run records inputs, outputs, errors, duration, and initiator (user, system, AI, webhook) at each step
- **Run Explorer**: Backoffice UI for investigating runs — filterable list, visual replay on the canvas, step-by-step data inspection
- **Draft/publish lifecycle**: Automations follow Umbraco's content model — draft, published, inactive. Version history with rollback. In-flight runs complete on the version they started with.
- **Access control**: Leverages Umbraco's existing user group/permission model
- **Failure notifications**: Configurable channels (email, webhook) per automation
- **Safety**: Rate limiting, kill switch (global + per-automation), timeout enforcement, trigger deduplication
---
## Load Balancing
Works out of the box in load-balanced Umbraco environments:
| Deployment | How it works |
|-----------|-------------|
| **Single node** | In-memory message transport. Zero external infrastructure. |
| **Multi-node** | All nodes poll the shared outbox table. Optimistic concurrency ensures exactly-once consumption. All nodes participate in trigger processing and step execution. |
Only scheduled (CRON) triggers are restricted to the SchedulingPublisher node. Everything else runs on any node.
Automate handles it itself. Scheduled triggers run on the SchedulingPublisher node, and everything else runs on any node but goes via a shared outbox table with optimistic concurrency, so you get exactly-once consumption across the cluster. No duplicate runs and no need for your own IServerRoleAccessor guard.
Researched with the help of AI.
Justin
Hey @Gavin5656 !
@justin-nevitech is correct, this was an important part of how we built Automate and it is documented in the source, but not anywhere else.
This information will be reflected in the official Docs once this PR is approved.
main ← automate/load-balancing
opened 02:17PM - 14 Sep 26 UTC
## 📋 Description
Adds a **Load Balancing** article to the Umbraco Automate do… cumentation for v17 and v18.
Automate already handles multi-node execution, but none of it was documented. This came out of a community question asking whether automations run on every node in a load balanced environment, and whether custom action code needs its own publisher check. The answer is no, and there was nowhere to point the person.
The new article covers:
* What each node does — trigger capture and outbox writes happen everywhere, consumption depends on the mode.
* The `Execution:Mode` setting (`SchedulerOnly` by default, `Distributed` for competing consumers).
* Why scheduled (CRON) triggers fire once across the cluster in both modes.
* Writing actions that are safe to run twice, since a stale claim is retried.
* Server role election, including the case where `ServerRole` never leaves `Unknown` and nothing runs at all.
* The **Automation Execution Eligibility** health check.
Also updates the **Configuration** article in both versions to include `Execution:Mode` in the settings sample and link to the new page.
Both versions of the new article are identical. The `Execution:Mode` setting and the health check are present on both the v17 and v18 release branches, so this describes shipped behaviour.
## 📎 Related Issues (if applicable)
None.
## ✅ Contributor Checklist
I've followed the [Umbraco Documentation Style Guide](https://docs.umbraco.com/contributing/documentation/style-guide) and can confirm that:
* [x] Code blocks are correctly formatted.
* [x] Sentences are short and clear (preferably under 25 words).
* [x] Passive voice and first-person language ("we", "I") are avoided.
* [x] Relevant pages are linked.
* [x] All links work and point to the correct resources.
* [ ] Screenshots or diagrams are included if useful.
* [ ] Any code examples or instructions have been tested.
* [x] Typos, broken links, and broken images are fixed.
Notes on the unchecked items:
* No screenshots. The article is configuration and behaviour, and the one UI reference (the health check) is a standard Health Checks entry.
* The `appsettings.json` samples are settings references rather than runnable instructions, so there is nothing to execute. The values and defaults were taken from the Automate source.
Vale passes with 0 errors and 0 warnings on all changed files.
## Product & Version (if relevant)
Umbraco Automate, versions 17 and 18.
## Deadline (if relevant)
Once approved