Action cost and the monthly cap
Found this helpful? Share it:
Found this helpful? Share it:
An Action spends credits the way a chat does, because every run is a chat. The cap is the part you control: it is a ceiling you set per Action, not a forecast.
The cap is the most one Action may spend in a calendar month. Set it when you create the Action and change it whenever the work changes. It is per Action, so a noisy digest cannot eat the budget of the one that matters.
The card shows what this Action has spent in the last 24 hours and in total since its first run. Each run also records its own cost, so the total is the sum of the rows in the run list rather than a separate estimate.
Before the first run the card says spend will appear after the first run. That is honest rather than empty: there is nothing to estimate from yet.
When a run would cross the cap, the run stops and asks instead of spending. The delivery is recorded, so you can see that the Action wanted to run and was stopped by its own ceiling rather than by a fault. Raise the cap or wait for the month to turn over, and the next delivery runs normally.
A run is skipped rather than queued when the previous one is still going, so a burst of events cannot multiply the spend. If you want fewer runs rather than cheaper ones, narrow the trigger with a condition or a debounce instead of lowering the cap.
Related articles
Was this helpful?