Skip to main content

Run automation unattended

A flow you supervise and a flow that runs at 3 a.m. are not the same flow. This is what to change before you leave it alone.

1. Make every ending explicit​

An unattended run cannot ask you a question, so every path has to end somewhere deliberate. Before scheduling anything:

  • Wire every failure port you care about. An unwired route kills the run with TRANSITION_NOT_FOUND — see Error codes.
  • Give each Stop a message. That message is what appears in the log, and the log is all you will have in the morning. "Not on a known screen after 2 BACK presses" tells you what happened; a node id does not.
  • Run Validate. An author-time error found at 3 a.m. costs you a night.

2. Raise the guardrails to match the real workload​

The defaults protect a flow you are watching. A long unattended run will trip them.

GuardrailWhy it fires overnightWhat to set
Max node executionsLoops multiply — 200 iterations over 12 nodes is ~2400 executionsRaise it deliberately when you add a loop, not after a run dies
Runtime duration capA long batch simply takes longer than a supervised testRaise it, or split the workload
Consecutive failuresA service being down looks like repeated action failureLeave this one strict — it is what stops a broken run burning all night

See Execution Model for what each one protects.

3. Put a precondition in front of the work​

Do not make the flow itself decide whether today is a day to run. Use the scheduler's Check Flow: a small flow that runs before the main one and decides whether it should run at all.

If the check failsBehaviour
Skip, retry next timeSkip this cycle, try again after the next cooldown
Stop this scheduleDisable the schedule until you re-enable it

Prefer Skip-retry unless a failed check genuinely means something is broken.

Keep the check tiny

Check Flow runs every cycle, before the main flow. A check that takes 30 seconds costs 30 seconds every cycle even when it passes.

4. Set a damage radius​

This is the step people skip. Two caps, both on the schedule:

  • Limit runs per day — a hard daily budget. Set this on anything that touches a real service. Progress shows on the dashboard as 4/8 today, and a flow that hits it shows Daily Limit Reached (not an error).
  • Only run within hours — confine triggers to a window, so a runaway cannot run at noon.

5. Give the interval room to breathe​

A schedule that fires while the instance is busy is skipped, and there is no catch-up. Ten missed hourly triggers do not become ten runs when the instance frees up.

So the interval must be longer than the run, with margin:

interval  >  worst-case run time  +  settle time

If your flow takes 8 minutes on a bad day, a 10-minute interval will spend its life reporting Skipped (busy). Make it 20.

If every cycle genuinely matters, lengthen the interval rather than hoping — the design deliberately drops missed triggers instead of building a backlog of stale work.

6. Get the timezone right before you sleep on it​

Every schedule carries its own timezone, and the time you type is in that zone. The Summary panel previews the resolved moment four ways — schedule timezone, your local time, UTC, and whether DST applies.

Read that preview before saving. A daily 08:00 in a DST zone drifts against UTC twice a year, and "it ran an hour early in November" is otherwise a mystery.

7. Decide what runs, and in what order​

The queue is a sequence, not a batch:

  • Order by dependency. If flow B assumes flow A left the app on a particular screen, they must be adjacent and in that order.
  • Use afterPreviousSuccess to make that dependency real instead of implied. Otherwise a broken first flow still lets the second run.
  • Selection is not order. An unselected flow stays in the queue, keeps its position, and is silently skipped — which is the right way to park one temporarily.

Remember: one instance runs one flow at a time. Concurrency comes from more instances, each with its own queue.

8. Leave yourself something to read in the morning​

  • Stop messages on every ending (step 1). This is your log.
  • Keep the queue's terminal history — success / failed / skipped per entry is your evidence when a schedule behaves oddly.
  • Do not leave Run Evidence on. It writes an image per action; overnight that is an enormous folder. Enable it only when reproducing a specific problem — see Debug a failed run.

Pre-flight checklist​

  • Validate passes with no blocking issues
  • Every failure route you care about is wired
  • Every Stop carries a message
  • Max node executions raised to fit the loops
  • Check Flow set, and small
  • Limit runs per day set
  • Interval comfortably longer than the worst-case run
  • Summary preview read, DST understood
  • Queue ordered by dependency, afterPreviousSuccess where it matters
  • Run Evidence off
  • Tested with Test Flow at least once end to end