How do I stop an automation from overspending?

#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

#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 contact added to a list at the last minute can miss this year. A rule only acts on dates far enough ahead to make the card in time, so somebody added three days before their birthday gets their first card next year.