Settings
The settings that apply to every automation: how the dashboard reads, what saved work is priced at, how much detail run logs keep, and the defaults that steps fall back on when they say nothing themselves. One form, two tabs, one Save.
An individual automation or step can override several of these values for itself—so read each setting as "what happens when nothing more specific has been said".
Main
| Setting | What it does |
|---|---|
| Dashboard Timezone Id | The timezone execution timestamps are rendered in on the dashboard, as an identifier such as America/New_York. Leave it blank and each viewer sees times in their own browser's timezone. Set it when a distributed team needs to be reading the same clock. |
| Labour Hourly Rate | What an hour of a person's time is worth, in US dollars. It turns the manual minutes an automation is estimated to have saved into a dollar figure on the dashboard. Leave it blank to use the platform's own default. |
| Capture Debug Logs | Whether the debug-level detail steps produce—request payloads, a script's debug output—is kept in each run's log. Off by default, because it is written to every run that produces any and is storage spent on detail nobody is reading. Turn it on while working out why an automation is misbehaving, then turn it back off. |
The rate here prices savings across the board; the per-operation rates behind those estimates are on the Savings Rates page. For what the figures mean, see Monitoring and history.
Nodes
Settings that govern how steps behave.
| Setting | What it does |
|---|---|
| Awaiting Input Timeout (hours) | How long a step waits for a person to answer before the wait is failed. It applies to every step that can pause for someone—an approval, a question from an agent, a mid-workflow form. Fractions are allowed: 0.5 is half an hour, and one minute is the smallest value accepted. Left blank, the default is 72 hours—three days, so a request landing late on a Friday is still answerable on Monday morning. An individual automation can override it. |
| Dry Run: Outbound HTTP | Which outbound requests are allowed to actually leave the system during a dry run. See the options below. An individual step can override it. |
| Default Model | The provider account and model every AI step runs on when neither the step nor its agent names one. It holds no credentials of its own—those live on the account it points at. Leave it unset to use the model the deployment itself is configured with. |
A run parked on a person is not spending its execution budget, which is why the Awaiting Input Timeout is the setting that decides how long such a wait may last. See Human in the loop.
Dry run policies
| Option | What it means |
|---|---|
| None | No request leaves the system. Every call is logged with its method and URL, and the step returns its test output instead of a real response. |
| Safe Methods Only | The read-only methods are sent for real, so downstream steps see live data; the methods that change things are logged and skipped. This is what applies when nothing is set. An endpoint is free to break the read-only convention—a fire-this URL, a webhook kick—so choose None if you cannot vouch for the endpoints being called. |
| All Methods | Every request is sent for real, including the ones that change things. A dry run rehearses nothing about outbound requests under this policy; choose it only when the endpoints are themselves test targets. |
For what a dry run is and how it differs from a test run, see Building automations.
Default Model
Default Model is the last of three tiers. A step's own override wins, then its agent's model, then this. The first tier that is filled in decides, and an empty tier falls through to the next—so with a Default Model and nothing else configured, every AI step runs on it.
A tier that is filled in but cannot be resolved fails the run rather than quietly falling through to the next one. If this setting names an account that has been deleted or can no longer be reached, steps relying on it fail and say so. For the full picture, see AI agents and models.
Where to go next
- AI agents and models—the three tiers, and the three fields of a model choice.
- Human in the loop—what happens when a wait times out.
- Building automations—test mode and dry run, and the per-step overrides.