What sprawl actually is
Sprawl is not the number of automations you have. It is the point at which four questions stop having answers: who owns this workflow, what it costs to run, what happens when it fails, and what breaks if I change it. A hundred well-owned automations are fine. Twelve unowned ones are an operating risk.
What a quiet failure costs
An automation that fails silently is worse than one that was never built, because the operation has already stopped doing the manual version. The failure surfaces as a customer asking where their order is, weeks after the retry loop gave up — and often the person who wrote the recipe has since changed roles.
Signals to look for
None of these is decisive on its own. Three or more together usually is.
-
The same recipe exists in three places
A near-identical automation runs in two boards and a base, each with a small variation nobody wrote down. Changing the rule now means finding all three first.
-
The customer notices before the owner does
Failures do not raise an alarm, they raise a support ticket. There is no queue where a failed run waits to be looked at.
-
Every tool counts usage differently
One vendor bills per action, another per step, another per run, another per item in a loop. Nobody can add them up, so nobody forecasts the number, so the first signal is an invoice or a hard stop.
-
Test runs and production runs are indistinguishable
Somebody debugging a workflow consumes the same capacity as the live operation, and there is no way to tell afterward which was which.
-
Credentials belong to a person
The integration authenticates as whoever set it up. When they change role or leave, a workflow stops and nobody knows why for a week.
How to evaluate it
Five steps, in order. Each one produces something you can put in front of other people rather than an opinion you have to defend.
- 01
Inventory before you consolidate
For every automation: trigger, actions, owner, credential, failure path. The list alone usually retires a third of them, and it is the only way to tell duplication from redundancy.
- 02
Count what each vendor counts
Read the metering rule for every tool — per action, per step, per run, per item in a loop. monday.com publishes its automation and integration pricing, and Airtable documents how automations are structured. Model your busiest week against those rules, not your average one.
- 03
Separate production from testing
You cannot control a number you cannot split. If building and running draw from the same undifferentiated pool, capacity planning is guesswork with a bill attached.
- 04
Decide the failure behavior on purpose
For each workflow: retry, alert, stop, or continue degraded. The default — retry quietly, forever — is a decision too. It is just not one anybody made.
- 05
Give every workflow an owner and a review date
A person, not a team. Sprawl is an ownership problem before it is a technical one, and consolidating without fixing ownership just produces tidier sprawl.
Where this leaves Bondi
Where Bondi fits
Bondi meters automation in one published unit, so the number is checkable rather than taken on trust. One Automation Run is max(1, ceil(billable Actions / 20)); triggers and skipped nodes are not billable actions. Runs draw from monthly plan capacity, then stackable capacity packs, then Wallet balance — and when the Wallet is empty, new over-capacity runs pause instead of accruing debt.
- 2,500 Runs a month on Standard and 15,000 on Pro, with stackable 5,000 Automation Runs packs at $49/month
- $0.02 per Production Run beyond capacity, deducted automatically from the Wallet
- Execution history, plus Service Accounts on Pro so no workflow runs on a personal credential
The other half of the answer
When Bondi is the wrong answer
- Your automations are few, owned and stable — the inventory is the whole fix
- The workflows belong to a product your engineering team already runs and monitors
- They need to stay where they are, and an integration is the answer rather than a migration
If one of these describes you, the honest recommendation is somewhere else. Nothing on this page is improved by pretending otherwise.
Common questions
Does every node count as a Run?
No. A Run is max(1, ceil(billable Actions / 20)), so one billable action and twenty billable actions both cost a single Run. Triggers and skipped nodes are not billable actions at all.
Do failed actions count?
A provider call that actually happened counts, including one that failed. Skipped nodes and the trigger do not. The point is that the number reflects work genuinely attempted, not work merely defined.
What happens when we run out of capacity?
Beyond included and add-on capacity, each additional Production Run costs $0.02 and is deducted from your Wallet. If the Wallet empties mid-execution, that execution finishes, the uncovered units are recorded without creating debt, and new over-capacity runs pause.
Can we keep the automations we already have?
Often, yes. Bondi reads and writes through typed actions and triggers, so an existing tool can stay in place for the part it does well while Bondi owns the data and the workflows that need tighter control.
Sources
- monday.com — Automations and integrations pricing checked 2026-08-03
- Airtable — Getting started with automations checked 2026-08-21
Claims about third-party products are limited to what these documents state on the date shown. Where a document is silent, this guide describes the product's design center rather than asserting a limit.