Safety & limits

Automation that spends your money needs brakes. MerchDash layers several, and none of them are optional.

How large a run can get

Automation rules and bulk actions are unlimited by default. A run is as large as the rule genuinely matches, and is written to Amazon in chunks however long that takes. Runs stream to the database rather than being held in memory, so there is no change cap of ours to hit and no per-account limit to set or raise.

Whoever operates your MerchDash install can still impose an install-wide ceiling on changes per run. Nothing sets one out of the box. When one is in force a run that reaches it stops and reports itself as incomplete, naming the number — so if you see a change limit you didn't set, that's what it is, and only your operator can lift it.

Two other ceilings can stop a very broad automation rule, and both say plainly what happened rather than quietly truncating: a run that evaluates for more than 60 minutes, and one that walks more than 5,000,000 rows. They exist so a single runaway rule can't monopolise the service, and normal rules never approach them.

Skip paused and archived campaigns (on by default) keeps a run pointed at work that matters: a campaign paused part-way through a rule's window still has data for the days before that, so without it a broad bid rule spends part of its budget rewriting bids that can never win an auction. Rules that are about campaign state — anything that can enable() or setState(), or that reads state itself — keep their paused campaigns automatically. See Settings.

Your maximum bid

Set a maximum bid in Bid limits and no bid MerchDash writes can exceed it — not a manual edit in Campaigns, not a bulk action, not an automation rule, and not the starting bid on a harvested keyword. A rule that computes $15 against a $0.80 Sponsored Products maximum writes $0.80, and the entry in History is marked adjusted with the reason, so a mis-typed multiplier costs you the ceiling instead of the computed number.

One maximum per ad product covers most accounts, and a single targeting type — substitutes, say — can be held tighter than the rest. There is no maximum by default. The full behaviour, including how a ceiling interacts with Amazon’s own $0.02–$1,000 range, is on Bid limits.

Evaluation budgets

Every run also carries generous execution budgets — on items processed, per-item metric reads, and total wall-clock time (60 minutes by default). Only pathological rules ever trip them; when one does, the run aborts with a clear error naming the limit, instead of running away. If a rule is stopped for taking too long, narrow its time range or conditions — a shorter window over fewer entities is far quicker than the same rule over a lifetime range. The time ceiling itself is an operator setting, so it can be raised for an unusually large account. Scripts are also size-capped, and the language deliberately has no file, network, or system access — a rule can read your ads data and call the documented actions, nothing else.

Because a run may legitimately take that long, Run now doesn't hold your browser open waiting for it: the run happens on the server and the page follows its progress. Closing the tab or reloading doesn't stop it — the rule row shows Running… again when you come back, and the result lands in History either way. Pressing Run again while one is in flight re-attaches to it instead of starting a second.

Two rules can run at once. Your account has two run slots; press Run now on a third and it joins a Rule queue under the running ones, starting by itself as a slot frees up. A queued run can be taken back out with the × beside it, or by clicking its position number on the rule row — nothing has happened yet, so nothing is undone. Pressing Run again on a rule that is already running re-attaches to that run rather than starting a rival one. Scheduled runs share the same slots, so a rule that comes due while two others are working starts a little late rather than piling on top of them.

Settled data by default

Rolling windows exclude the two newest, still-settling attribution days, so a rule never punishes a keyword for sales that simply haven't been attributed yet. This is a data-correctness guardrail as much as a feature — details in Attribution & settled data.

Review mode and the full revert trail

Rules in Review mode change nothing until you approve the run. Either way, every change lands in Change history with before/after values and a reason — and any change or whole run can be reverted for as long as the run is in your plan’s automation-history window (14 days on Starter, 45 on Growth, 90 on Scale). Reverts are logged as their own linked entries, so the audit trail is never rewritten.

No-op protection

Applying a change always checks the live state at Amazon first and skips no-ops — pausing an already-paused keyword does nothing rather than recording a phantom change, even if MerchDash's synced state was briefly stale.