Workflow operating costs

A workflow’s operating cost covers platform usage, connected-service charges, hosting and storage, and time spent resolving failures. Begin with the work the integration must complete, then apply the billing rules of the products you actually use. A run count alone is not a cost estimate.

For a paid-order integration, the intended result might be one confirmed fulfilment request per eligible order. To reach it, count the checks and actions needed, including checks that find no work and attempts that fail or repeat.

Build a workload ledger

Choose a billing period. In separate columns, record eligible source items, trigger checks or event deliveries, workflow runs, actions, outbound API calls, retries and confirmed outcomes. One run can process several records; one record can cause several runs.

Use both an ordinary and a busy period. Record the workflow version and plan beside the estimate: a changed step, schedule or entitlement can change the result.

Apply the right meter

Make uses credits, generally one credit per non-AI app operation. A scheduled trigger check is an operation even when it finds nothing.

Licensed n8n plans shown on its pricing page use workflow executions rather than a per-step meter. Azure Logic Apps Consumption meters eligible trigger and action executions under its operation rules. None of these units establishes what a connected application charges.

For the selected deployment, check which operations are included, metered or covered by an allowance. Include branches, loops, retries and features with different rates. Use the actual connector and plan terms before assigning currency amounts.

Compare spending with useful work

For the same cohort and period, divide measured spending by confirmed eligible outcomes. Show unresolved work alongside the figure. A low cost per completed item can hide orders that never triggered, or expensive cases still waiting for a result.

For diagnosing individual no-change runs, see the sibling article.

Keep the spending period and outcome cohort consistent when comparing results over time. If the workflow’s retained run history or connector usage changes, record that alongside the outcome measure. This prevents a change in platform activity being mistaken for a change in the cost of useful work.

Key Metrics for Workflow Cost Monitoring

Separate execution and retention charges

Azure Logic Apps Consumption includes an initial number of free built-in operation executions per Azure subscription; above that allowance, eligible executions are metered. Managed connectors follow separate connector pricing, so an allowance for built-in operations does not establish the cost of every connected service.

Consumption storage metering applies to data-retention use, such as saving workflow inputs and outputs in run history. Retained execution data is therefore a distinct cost driver from the trigger and action executions that process the work.

Azure meters an operation execution even when the workflow does not complete successfully, finish or become instantiated. An operation usually makes one execution, but enabled retry attempts can result in further executions. An outcome count alone may not represent billable activity.

Top 3 Factors Influencing Workflow Cost in Australia (2026)

Understand what changes a credit count

In Make, an operation is a module run to process data or check for new data. A module can run more than once as it processes bundles. A trigger module runs once per check, regardless of how many bundles it returns.

For non-AI apps and third-party AI apps, one operation equals one credit. Built-in AI features can use a different basis: Make’s AI Provider uses tokens and operations, while automatic AI provider connections can also factor in other usage-based measures. Check the applicable connection type rather than assuming every module has the same credit cost.

Use budget signals with their timing in mind

Azure Cost Management budgets can be set against actual or forecast costs and can reset monthly, quarterly or annually. Cost and usage data is typically available within 8–24 hours. Budgets are evaluated against that data every 24 hours; email notifications are normally sent within an hour after an evaluation finds a threshold has been exceeded.

A budget is a notification mechanism, not a control that suspends workflow consumption. Allow for the data and evaluation delay when deciding how quickly someone must respond to a spending signal.

Budget Signal Timing in Azure Cost Management

Choose a change that preserves the outcome

For a comparison of schedule, event-delivery and batching trade-offs, see the sibling article.

Set a usage signal for the relevant meter and assign someone to investigate a spike.

After a design change, compare the forecast with a real billing period and with source and destination records.