7,000 tasks a day: how Workato recipe pricing compounds

Workato bills per task — one task is one action executing inside a recipe run. A seven-action recipe firing a thousand times a day is 7,000 tasks, not one. That figure sets your tier, and the tier price is not published: you learn it after a sales call. Overages run two to three times the bundled rate, SAP and Oracle connectors carry a premium, and recipe counts drift upward on their own. The bill compounds along three axes.

What is a task, and why is it not one per order?

Workato's meter is the task: a single action executed inside a recipe. A recipe is one automation — a trigger plus a sequence of actions — and every action it runs draws a task. So the unit you pay for is not the business event that started the recipe; it is each step the recipe takes to service that event. Reviewers put the arithmetic plainly: a seven-action recipe run a thousand times a day generates 7,000 tasks. One order in, seven twitches out.

That gap between events and tasks is where the bill first detaches from the work. A recipe that enriches an order, checks stock, writes to two systems, posts a confirmation and logs the result is doing one job in business terms and five to seven in billing terms. Add a loop over order lines and the multiplier compounds again: ten lines through a three-action loop is thirty tasks for what a human would call a single order. Retries, error branches and polling triggers all draw from the same meter. You are billed per twitch, not per outcome.

Why can't you see the price until you have booked the sales call?

Workato does not publish recipe-tier pricing. Community write-ups are blunt about the mechanic:

You only find out the number after talking with sales.

The visible reference points come from buyers comparing notes rather than from a price sheet. Third-party guides put common tiers at 20 to 100 recipes for roughly $50,000 to $150,000 a year as of May 2026 — a band wide enough that where you land inside it is a negotiation, not a lookup. The unit that sets the tier, the recipe, is also the unit your teams create freely, which means the thing driving your price is the thing you are actively encouraged to make more of.

What happens when 20 recipes quietly becomes 60?

Recipe counts creep, because building another recipe is the path of least resistance every time a new integration need appears. The community observation is consistent:

a team that starts with 20 recipes often finds itself at 60+ within 18 months… triggering contract renegotiation at a higher tier.

Read against a tier band that runs from $50,000 to $150,000, that trajectory walks you across pricing brackets on its own. Nobody decides to triple the bill; each recipe is individually justified, and the sum crosses a threshold that reprices the whole estate. It is the same decoupling of what you pay for from what you actually use that we flagged in professional-services hours that expire — spend that grows by accretion rather than by decision, and surfaces as a renewal surprise.

Where do the surcharges hide?

The tier price is the floor, not the total. Two documented add-ons sit on top of it, and both scale in the wrong direction. Connectors to the systems you most need — the ERP endpoints — carry a premium of 15-30% on top of your base cost for the SAP and Oracle connectors specifically, as of May 2026. The connectors you would happily skip are cheap; the ones a route-to-market estate cannot function without are the surcharged ones:

15-30% to your base cost

That is the same logic as paying per connection on a platform where the batch fails whole: the pricing lever is bolted to the integration you are least able to remove. And the SAP endpoint on the other side of that premium connector carries its own upgrade tax every time a transport lands, so the surcharge buys you a link to a moving target.

The second add-on is the overage. Task bundles are sized to a forecast, and when a busy month blows through the bundle, the excess is not billed at the bundled rate. Per third-party pricing analysis, overage rates:

can be 2-3x higher than bundled task rates.

Combine that with the way a single order fans out into seven or more tasks, and the exposure is obvious. The months you most want elasticity — a promotion, a peak-season order spike, a retry storm after an outage — are exactly the months your task count balloons and every excess task is billed at two to three times the rate you budgeted. The pricing punishes precisely the load you cannot schedule.

Why is this a pricing-model problem, not a negotiation problem?

You can grind any single number down at renewal and still lose, because the model itself couples your bill to activity rather than to value. A task is a twitch of the machine; it fires whether the recipe did anything useful or spun through a retry loop and gave up. The meter sits below the level where value is created — at the action, not the outcome — so the engineers who create cost by adding recipes and actions never see a running total, and the people who own the budget are handed a figure they cannot decompose into levers they control. Adoption and overspend become the same event: every team that succeeds with the platform makes the bill less predictable.

That is the structural difference between pricing per twitch and pricing per deploy. An automation platform meters the count of little machine actions; an event-driven service meters the thing you actually ship and run. When the unit is the action, growth in usefulness looks identical to growth in cost, and no amount of tier negotiation changes the sign of that relationship. The three axes — tasks per recipe, recipes per estate, surcharges per connector — are not three separate leaks to plug; they are three faces of one decision to meter the machine rather than the work.

The direction out is to move the meter to something you can name and cap. When integration runs on a single event bus we instrument ourselves, spend maps to events and deployments we control, not to a synthetic task count that multiplies with every action a recipe happens to take.

Teams reviewing their 2026 integration spend will not get far by haggling over the per-task rate. The question worth asking before the next renewal is whether an integration layer should be priced by the count of machine actions at all — because as route-to-market estates get busier, a meter that rewards more twitches per order gets more expensive precisely as the platform gets more useful, and that is the wrong incentive to sign up for twice.