Automations

Every automation follows a decision tree structure with three tiers:

Triggers determine when an automation runs and which path to take. Each trigger type has two states that route to different actions.

Execute based on a recurring schedule with configurable days and times.

Use cases:

• Business hours bandwidth boost (9am-6pm weekdays)
• Weekend maintenance windows
• Peak/off-peak pricing optimization

Execute based on host availability (ping monitoring).

Use cases:

• Failover bandwidth when primary host goes down
• Automatic recovery when service comes back online
• Load balancing based on server availability

Execute when an external HTTP request is received.

Use cases:

• CI/CD pipeline triggers (deployment events)
• Integration with external monitoring systems
• Manual triggering via API call

Execute once at a specific date and time.

Use cases:

• Scheduled maintenance windows
• One-off events (product launches, streaming events)
• Temporary bandwidth increases for specific occasions

Actions perform the actual bandwidth changes. Each trigger state can have its own action configuration.

The primary action type that modifies circuit bandwidth.

A placeholder action that does nothing. Useful when you only want to notify without making bandwidth changes on one of the trigger paths.

Notification actions send messages about execution results. Configure credentials per-node — paste literals or reference shared values via Account → Environment with {{secrets.NAME}} / {{vars.NAME}} expressions (see Variables & Secrets below).

Send email notifications via Postmark.

Send notifications to a Slack channel via incoming webhook.

Send notifications to a Teams channel via incoming webhook.

Click the power icon on an automation card to toggle its enabled state. Disabled automations won't execute their triggers.

For testing or emergency situations, you can manually trigger an automation:

Variables and secrets let you store shared values (hostnames, API keys, test fixtures, default thresholds) once and reference them from any automation node — instead of pasting the same literal into every node and chasing down every copy when it changes.

Both come in two scopes:

• User scope — owned by you, available to every automation. Manage at Account → Environment.
• Automation scope — bound to a single flow. Manage from the Variables tab in the automation editor sidebar. Use for per-flow test fixtures, pinned data, anything that's only meaningful inside one workflow.

Account → Environment also shows a read-only inventory of every automation-scope variable and secret you own, grouped per automation. Useful for auditing what's where without opening each flow individually. Edits still happen in the editor (where you can see how the value flows through the nodes); delete is available inline from the inventory.

Reference either scope from any node field with:

When the same name exists at both user and automation scope, the automation scope wins for that flow — so a flow can override a user-level default with a per-flow value without touching the user-level row.

Secrets are stored in one of two modes — the inspector decides automatically based on what you type, so you don't have to choose explicitly:

• Literal — the value is encrypted with industry-standard encryption. The plaintext can never be shown again; rotating requires pasting a new value. Use for API keys, tokens, passwords.
• Expression template — the value is a {{…}} expression that resolves to the real value at run time (e.g. {{secrets.OTHER_TOKEN}} as an indirection layer, or {{vars.PREFIX}}{{secrets.SUFFIX}} composing pieces from different sources). The template itself isn't sensitive (anyone reading it sees only the expression, not the resolved value), so it's shown in the inspector. The resolved value is still masked in logs.

Every variable and secret inspector has a single Secret toggle. Flipping it changes the row's kind at the next Save:

• Variable → Secret — silent. The current value is encrypted (or stored as a template if you typed a pure expression). No confirmation needed.
• Secret → Variable — for expression-mode secrets, silent. For literal secrets, the inspector asks you to confirm — converting would expose the previously-encrypted value as plain text — and clears the value so you must type the replacement explicitly before saving.