Skip to main content
Paused keeps collecting. Off doesn’t. That’s the whole distinction.Pause when you want to hold processing without missing anything, an integration is misbehaving, or you’re rewriting instructions and want the new logic to apply to the backlog. Turn off when you genuinely don’t need the automation.Runs already in flight finish under both.
One subtlety for schedules: Off skips the occurrences missed while it was off, so you don’t get a flood of catch-up runs. Paused retains them.
Because work arrived faster than one of two limits allows. Nothing is dropped. It waits.
  • Maximum concurrent runs: how many runs of this automation can be in flight at once. It starts at 3 and you can set it between 1 and 5. Set it to 1 to force strictly one-at-a-time processing.
  • Daily run limit: how many runs can start per day. Defaults to 100 and resets at midnight UTC. Contact us to raise it.
There’s also a company-wide concurrency ceiling across all your automations combined, separate from the per-automation setting. If the queue shows “Company concurrency limit reached”, that’s this one, several automations were running at once, not one automation exceeding its own limit. It clears on its own as runs finish.The limits exist to contain blast radius: a noisier-than-expected automation shows up as a backlog rather than burning through your usage in an afternoon. The automation library shows a backlog count so you can spot one building without opening it.
There’s no simulation mode. Two things work instead:
1

Build the routing without the action steps first

Let a real trigger fire it, and read the run history to see which decisions were made. Nothing is touched because there’s nothing attached yet. Add the actions once the routing looks right.
2

Or save it and let a real event fire it

Then read run history.
The first approach is the safer one for anything that emails a customer or writes to your billing system.
Yes. Every save creates a version, and the version indicator is a dropdown. Open it to see past versions and select one to view.Reverting takes one non-obvious step:
1

Select the older version from the dropdown

2

Drag a node slightly

This registers a change.
3

Save

That older shape becomes the new current version.
You’ll get a warning if you save while viewing an older version, since newer changes can be lost.
Edit history is changes to the automation, who changed it, when, and what differed between versions.Run history is actual executions, in three views:
  • Runs: everything that ran, and which route each one took.
  • Filtered out deterministically: events stopped by fixed rules before any agent work happened. These don’t count against your limits.
  • Queue: events waiting to be processed.
The maximum wall-clock time for a single run, defaulting to 60 minutes. It’s a safety net so a stuck run can’t hang around indefinitely.It applies to runs dispatched after you save the change. Most people never touch it.
Yes, there’s a Run manually trigger type, and saved automations can be started on demand. Two conditions:
  • The automation has to be saved. You’ll be prompted to save or discard editor changes first.
  • The automation has to be On. A paused or off automation can’t be run manually.
No. Approvals land in an approval inbox inside LedgerUp. Slack is one destination, not the only one.This holds even when an automation ends in Silent Completion with no Slack step at all, the approval request still reaches the inbox. The Slack step controls where the summary is posted, not where approvals go.You can create one inbox per workstream or per priority level, so requests arrive in their own queue rather than a general pile.