Controlflow#

#Overview

Controlflow is the rule-based automation engine in Braiins Manager. You define rules that combine targets, optional conditions, and an action. Controlflow evaluates rules on a schedule or on a polling interval and applies the action to every qualifying worker.

Controlflow supports two rule types:

• Scheduled Rules: Time-based. Run once or recur on a daily, weekly, or monthly schedule. Conditions are optional.
• Trigger Rules: Interval-based. Poll on a fixed cadence (15, 30, 45, 60 minutes, or a custom 2 to 12 hour interval). Conditions are optional for most actions and required for the Do Nothing action.

Common automation patterns include scheduled curtailment, thermal protection, pool-drift correction, and automated customer assignment after onboarding.

#Access and Permissions

Controlflow is part of the Pro Plan. Providers without an active subscription see a promotional page instead of the Controlflow UI.

• Provider Admin can self-start a time-limited trial and has full access to Controlflow across the provider account.
• Provider Account with access to the Controlflow component can use Controlflow within their permitted Locations. Some users are restricted to a single Location; those users can only target that Location and the Groups and Racks inside it.

#Key Concepts

• Rule: The top-level automation object. Has a name (max 48 characters), an active flag, one or more targets, an optional timezone, and a priority.
• Event: A sub-unit of a rule that pairs a start time (Scheduled) or polling slot (Trigger) with an action and optional conditions. A rule may have up to 5 events.
• Target: The set of workers the rule applies to. Multiple target types on a single rule are intersected: a worker must match all target criteria to be eligible.
• Condition: An optional filter applied at execution time. Workers that fail the conditions are excluded from the action.
• Action: The operation Controlflow performs on qualifying workers.
• Priority: A numeric rank from 1 to 1000 that determines execution order when multiple rules fire in the same polling window. Lower numbers run first.
• Execution Window: The look-back used when evaluating numeric conditions. Immediate uses the most recent value (up to 7 minutes old); a rolling window of 10 to 60 minutes (in 5-minute steps) supports Average, Median, Min, or Max aggregation.
• Invalid Configuration: A flag set automatically on a rule when a Location, Customer, Group, Rack, or license preset it references is deleted. The rule is auto-disabled. The flag does not clear automatically; you must edit and re-save the rule.
• Rule History: An immutable log of executions. Retained for 2 months.

#Create a Rule

1. Open Controlflow from the main navigation.
2. Click Add Trigger Rule or Add Scheduled Rule.
3. Enter a name (up to 48 characters).
4. Select one or more targets.
5. For a Scheduled Rule, pick a timezone. For a Trigger Rule, pick a polling frequency.
6. Add up to 5 events. Each event has its own action, optional conditions, and (for Scheduled Rules) a start time and optional recurrence.
7. Optionally configure aggregation gating, per-device execution limits, and notifications per event.
8. Review the Targeted Device Count preview - the form shows a live count of workers that match the current target configuration.
9. Save the rule. It becomes active immediately.

#Trigger Rules

Trigger Rules poll on a fixed cadence and act when the targets (and any conditions) match at that moment. Available frequencies:

• 15, 30, 45, or 60 minutes
• Custom interval from 2 to 12 hours (must be a multiple of 60 minutes when above 60)

Trigger run slots are pre-generated 2 days ahead and replenished daily by a background job.

#Scheduled Rules

Scheduled Rules execute at specific calendar times. Each event can be:

• One-time at a specific date and time, or
• Recurring daily, weekly on chosen weekdays, or monthly on a chosen day, with a configurable repeat interval.

Scheduled run slots are pre-generated 31 days ahead and replenished daily.

#Duplicate Detection

Two rules with the same type, targets, action, and timing are treated as duplicates. The second save is rejected.

#Targets

A rule must have at least one target. When multiple target types are added, they are intersected - a worker must satisfy all criteria to be eligible.

Available target types:

• Locations
• Customers
• Sitemap Groups (from the Sitemap)
• Sitemap Racks
• Device Models
• IP Ranges
• Firmware Type (Braiins OS or stock)

A location-restricted Provider has their Location automatically injected into the target calculation, so the preview always reflects only their permitted scope.

#Actions

The available actions are:

• Pause Mining
• Resume Mining
• Reboot Device
• Set Performance Mode (stock firmware only)
• Set Power Target (BraiinsOS) (Braiins OS only)
• Set Pool Configuration
• Assign Customer
• Apply License (BraiinsOS) (license-based, Braiins OS only)
• Check License (BraiinsOS) (Braiins OS only)
• Do Nothing (notification-only - requires at least one condition)

A location-restricted Provider can only use license presets assigned to their Location.

#Conditions

Conditions filter workers at execution time so the action runs only against the subset you want. Conditions are optional for normal actions; the Do Nothing action requires at least one condition.

#Numeric Conditions

Apply thresholds to live telemetry. Available metrics:

• Power (W)
• Temperature (degrees)
• Hashrate (TH/s)

For each numeric condition, you choose:

• Operator (greater than, less than, between, etc.)
• Threshold value
• Execution Window - Immediate (last reported value, up to 7 minutes old) or a rolling window of 10 to 60 minutes in 5-minute steps, with Average, Median, Min, or Max aggregation.

If no telemetry point exists within the look-back window, the worker is treated as no match and excluded from the action.

#Status and Lifecycle Conditions

• Is Under Curtailment - workers currently in an active Curtailment window.
• Customer Is Not - excludes one or more specific customers.
• Agent Is Offline - workers attached to a Location whose Agent is currently offline.
• Pool Configuration Is Different - workers whose active pool configuration does not match a specified desired pool set.
• Hashing Status Transition - workers that have transitioned from a chosen "from" status to one of the chosen "to" statuses within the evaluation window, with no intermediate transitions in between.
• License State (Braiins OS only) - workers in a specific Braiins OS license state.

#Time Range (Trigger Rules only)

The Time Range condition gates the entire trigger run by a daily window relative to the rule's timezone. If the current time is outside the window, the run is skipped entirely; workers are not individually filtered.

#Aggregation, Limits, and Notifications

These three controls are configured per event and shape when and how often an action runs.

#Aggregation Gating

Aggregation gating evaluates after conditions have been applied. The action runs only if the matching worker set satisfies a threshold:

• Count - the number of matching workers meets a threshold.
• Percentage - the ratio of matching workers to all targeted workers meets a threshold.
• Load - the combined power draw (MW) of matching workers meets a threshold.

If the gate fails, the run still moves to history with an affected-worker count of zero. If zero workers match the conditions, the action is not executed.

#Per-Device Execution Limit

Limit how many times a worker can receive the action per day, from 1 to 96. A worker that has already received the action the allowed number of times in the current day is excluded from further runs until the daily reset.

#Notifications

You can attach a Telegram bot recipient to an event. Notifications fire only when at least one worker was affected. Configure recipients in Settings > Integrations before referencing them here.

#Priority and Conflict Resolution

When multiple rules fire in the same polling cycle, Controlflow resolves overlap as follows:

1. Sort rules by priority (lowest number first), then by rule creation timestamp, then by event index.
2. Execute rules in that order.
3. A worker acted on by a higher-priority rule is excluded from lower-priority rules in the same cycle. (Other workers in the lower-priority rule's set are still processed.)

This avoids double-execution while still letting independent rules act on disjoint worker sets.

#Reorder Priorities

To change the order:

1. Click Change Priority on the Rules tab.
2. A drag-and-drop modal lists all rules ordered by current priority.
3. Reorder and save. Priorities update atomically; duplicate priorities are rejected.

Reordering is available to Provider Admins and to Providers who are not Location-restricted.

#Manage Rules

The Rules tab is the main place to view and manage your automations.

From the Rules tab you can:

• Search and filter rules by state, type, frequency, action, Location, or Customer.
• Toggle a rule active or inactive (a confirmation modal appears for the disable direction).
• Edit, clone, or remove rules.
• Open a quick-view panel with full rule details.

#Enabling and Disabling

• On enable: future runs are regenerated for Trigger Rules; existing future runs are re-activated for Scheduled Rules. Re-enabling a Trigger Rule discards any pre-generated stale runs and regenerates them from the current moment, avoiding backlog catch-up.
• On disable: all future runs are marked inactive and will not execute.

#Invalid Configuration

If a rule references a resource that is later deleted (Location, Customer, Sitemap Group or Rack, license preset), Controlflow:

1. Auto-disables the rule.
2. Sets the Invalid Configuration flag.
3. Writes a warning event to the provider event log.

The flag does not clear when the underlying issue is fixed - edit the rule, adjust the broken reference, and re-save to clear it.

#Upcoming Events

The Upcoming Events tab is a calendar view of pending Scheduled and Trigger run slots.

• The view spans a date range of up to 5 days (past or future).
• Click a run to see its rule, targets, action, and conditions in a quick-view panel.
• Skip an individual upcoming run to prevent it from executing without disabling the whole rule. A skipped run stays visible in the calendar and can be re-enabled before it fires.

#History

The History tab logs every rule execution.

Each entry records the rule name, action, affected-worker count, frequency, and timestamp. From the tab you can:

• Filter by date range, action type, Location, Customer, rule type, or affected-workers flag.
• Search by rule name.
• Open the per-worker drilldown to see the individual workers acted on for recent runs (worker ID, IP, and MAC for each).

History records are retained for 2 months, after which a background job removes them.

#Real-World Examples

Common patterns customers run with Controlflow:

• Scheduled curtailment: Pause and resume mining around known energy-tariff windows; combine with Curtailment for price-driven shutdowns.
• Reactive thermal protection: A Trigger Rule that pauses mining or reduces power when temperature exceeds a threshold, with a per-device daily execution limit to avoid loops.
• Underperforming worker reboot: A Trigger Rule that reboots workers whose hashrate is below target and whose temperature is within safe limits, capped at a daily execution count.
• Pool-drift correction: A Trigger Rule using the Pool Configuration Is Different condition with Set Pool Configuration as the action.
• Automated customer assignment: A Scheduled Rule that runs once after onboarding to assign workers to a Customer by IP range or Location.
• Coordinated maintenance: Scheduled Rules that pause and resume mining for a targeted Group or Rack during a maintenance window.

More patterns on the Braiins blog:

• Introducing Controlflow: Advanced Automation in Braiins Manager
• Controlflow Update: New Trigger Rules

#Best Practices

• Start small. Build a rule against one Location or a single Group, watch it run for a cycle or two, and then widen the scope.
• Use conditions to prevent unnecessary work. A Trigger Rule with no conditions will act on every targeted worker each cycle.
• Set per-device execution limits on Trigger Rules that issue heavy actions (reboot, set power target) to avoid runaway loops.
• Check firmware compatibility. Some actions are firmware-specific and will short-circuit if your target set has no matching workers.
• Watch priorities. Two rules that target overlapping worker sets should have meaningful priority ordering, otherwise execution within a cycle is determined by creation timestamp.
• Re-save rules after deletions. When you remove a Location, Customer, Group, Rack, or license preset, any rule referencing it is auto-disabled with an Invalid Configuration flag - edit and re-save to clear it.

---

Was this helpful?

Yes, thanks!Sort of, thanks!Not really