How do I stop an automation from overspending?
Set Cap for the year on the rule. The count is checked before every single card, and it resets on 1 January, so a rule capped at 500 does not stay stopped in its second December. On top of that, a rule can never send two cards for one occurrence, and it always skips anyone on your do-not-mail list.
On this page
#The annual cap
An evergreen rule against a growing list is an open-ended bill. A birthday rule pointed at everyone will happily follow a headcount from 40 to 400 without anybody deciding that was fine.
- The cap is checked before every card, not at the end of a run.
- When it is reached the rule stops and says so, rather than quietly spending.
- The counter resets with the calendar year.
- A sensible starting cap is your list size plus about 20%.
#Everything that makes a rule skip somebody
| Reason | What you see | What to do |
|---|---|---|
| Annual cap reached | The 500-card annual cap for this rule is used up for 2026. | Raise the cap. |
| No credits | No credits left. Top up and this contact is picked up on the next run. | Top up. They are picked up while their date is still in the catch-up window. |
| Do-not-mail | On your do-not-mail list. | Nothing, unless it was a mistake. |
| Missing merge value | The message needs company, which this contact has no value for. | Fill the field in, or set a fallback on the rule, or take the field out of the message. |
| Occurrence already claimed | Nothing — this is silent and correct. | Nothing. It means the card already exists. |
#What cannot happen
- A rule cannot send the same person two cards for one occurrence. The claim is a unique database constraint, inserted before the order exists, so a retry or an overlapping run collides instead of duplicating.
- A rule cannot spend credits you do not have. The balance is checked before every card and the spend goes through a database function rather than a read-then-write, so two concurrent sends cannot spend the same last credit.
- A rule cannot mail somebody on the do-not-mail list, even if a fresh import recreated them as a contact. That is the entire point of that list.
- A rule cannot mail an address it cannot write. Anything incomplete lands as Held and is not charged.
#What can still happen, so check it
- Two rules can both write to the same person. The duplicate guard is per rule. Overlapping lists produce overlapping cards.
- An inbound hook fires once per POST. If your Zap or Flow can fire twice for one event, that is two cards and two credits. Guard the trigger, not the card.
- A rule with a lead time that is too short still creates cards. They will be late. See lead time.
Last checked against the product on . Something wrong or missing? Tell us.