How actions are counted
What uses your monthly allowance and what does not.
One step that runs to a result is one action. That's the whole rule — the rest of this page is what "runs to a result" means in the cases where it isn't obvious.
What counts
| Counts | |
|---|---|
| The trigger that started the run | Yes |
| An action that succeeded | Yes |
| An action that failed | Yes |
| A filter that evaluated | Yes |
| A branch that chose a path | Yes |
| A delay, once it finishes waiting | Yes |
| A step that was skipped | No |
| A step in a cancelled run | No |
| Testing a step while building | No |
The two that catch people out are at the top and in the middle: the trigger counts, and failures count.
Why the trigger counts
Receiving and processing the event is work — the webhook arrives, the payload is parsed and stored, and the run starts. A three-step automation is therefore three actions per run: the trigger plus two actions.
When you're estimating usage, count every box in the automation, not just the ones that call another tool.
Why failures count
A step that fails has already done its work. The request went out, the other tool considered it, and it came back with an error. The cost is the same as a success; only the outcome differs.
A failed step isn't retried automatically, so one failure is one action — it won't quietly consume your allowance in a retry loop. Fix the cause and re-run when you're ready.
Why skipped steps don't count
When a filter doesn't match, the steps after it never execute. Nothing was sent anywhere, so nothing is charged.
This is worth designing around. Put the filter as early as you can and a high-volume trigger becomes cheap: the trigger and the filter cost two actions, and the expensive steps only run on the events that matter.
A run like that finishes as completed, not stopped or failed — it did exactly what you asked, which was nothing further.
Delays
A delay costs one action, charged when the wait ends rather than when it begins. Waiting itself is free, whether it's ten minutes or ten days.
If your allowance runs out while a run is mid-delay, the run fails when the delay ends rather than resuming.
Sub-automations
A sub-automation call is charged on both sides:
- The calling step counts as one action, settled when the sub-automation returns.
- Every step inside the sub-automation counts too, including its own start step.
So a parent with three steps calling a sub-automation with two costs six actions in total — three in the parent, plus the sub-automation's start step and its action.
Testing while you build
Testing a step in the editor doesn't count. Test as much as you need — usage only accrues from live runs.
Bear in mind that a test still performs the real operation in the other tool. It's free for your Nodest allowance, not free of consequences in the connected app.
When usage is recorded
Usage is recorded as a run progresses, not when it finishes. A long-running automation consumes its actions along the way, and each step is counted once even if the run later resumes after a delay or a sub-automation.
Your current total is on the billing page, under Action usage this cycle.
