Schedules
A flow can carry several schedules, not just one. Each schedule runs the same flow on its own cron expression, which is how a single flow runs more than once with different parameters - for example, once per branch. Each schedule has:- Enabled: a toggle that controls whether the schedule fires at all. Disabling a schedule does not delete it; re-enabling it resumes firing on the configured cron expression.
- Cron expression: a standard cron string that determines when the schedule fires. Expressions are evaluated on minute ticks, so the finest granularity is one run per minute.
- Preset assigns: named values seeded into the run before the graph is evaluated. This is what lets several schedules drive the same flow differently - see below.
Preset assigns
A schedule’s preset assigns are an ordered list of named values written into the token’s assigns before the flow starts evaluating. Each entry pairs an assign key with a value specification, resolved the same way a FlowCompose field is, so typed values - dates especially - survive being queued and run later. Preset assigns are the mechanism for parameterising one flow across schedules: give each schedule a different preset and the same graph does different work on each cron. A preset overrides any matching FlowDefault value in the graph - the default only applies when no preset, and nothing upstream, supplied the value.Log verbosity
There is no single run-wide verbosity setting that gates a run’s logs. Instead, each node decides how much it contributes to the log, and every run - manual or scheduled - uses those same per-node settings. There is deliberately no per-run or per-schedule log-level override: a scheduled run logs exactly what a manual run of the same flow would. All log levels sit on one scale, from quietest to most verbose: debug → info → warning → error How a node participates depends on which node it is:- Flow Log nodes always emit. A Flow Log line is written to the run log every time, regardless of any floor. Its level is purely a display stamp - it controls how the run viewer colours and filters the line, not whether the line appears.
- Every other node has a floor, defaulting to
error. With the default floor, only a node’s crashes and halts surface; its routineinfo-level output is dropped. Lower an individual node’s floor from its inspector to see more of what it does, or lower them all at once from the editor’s Settings pane.
The run log
While a flow is running, log entries written by nodes are appended to an in-run log buffer and broadcast live to any editor pane watching the run. When the run finishes, the buffer is snapshotted onto the FlowRun row so the entries remain available in the run history afterwards. Early lines, such as the “run started” marker, are seeded into the live view as well, so a pane that attaches mid-run still shows everything from the top. Two distinct logging surfaces exist:- The run log is what nodes write to describe what is happening in the run. It appears in the editor’s run view and in the FlowRun’s recorded log. Internal detail, identifiers, and other potentially sensitive values are fine here - this log never leaves Twine’s own storage.
- System logs are routed to Twine’s internal logging and monitoring infrastructure. This path is reserved for hard run failures - a run that failed evaluation or aborted, plus failures that happen before a run can start. It is never used for normal-path markers like “run started” or “run finished”, and must not carry personally identifiable information at
infoor above.