Meta automated rule not working? Prove it ran
A Meta automated rule that never fires looks exactly like a healthy account. How to find the silent causes and prove the rule evaluated at all.
A Meta automated rule that never fires looks exactly like a healthy account. How to find the silent causes and prove the rule evaluated at all.
The rule went in six weeks ago: pause any ad set whose 7-day ROAS drops below 1.2. Since then it has paused nothing. In the Monday call somebody calls that good news, so the account must be healthy. Then somebody asks the question nobody in the room can answer. Did the rule look and decide not to act, or did it stop looking?
Short answer: When a Meta automated rule is not working, the usual cause is silent: a condition that can never be met, a rule scoped to IDs that no longer exist, a schedule reading half a day, or a stale input. None of these throws an error. Check the rule's own result history, then force a test trigger.
The takeaways
A Meta automated rule stops working silently because every one of the common causes is a valid configuration. The rule runs, reads its window, finds no match, and moves on. Nothing about that is an error.
The one I find most often is the guard that never opens. You add a minimum-spend line so the rule cannot judge an ad set on two days of data. Sensible. Then the account shrinks, budgets drop to €30 a day, and €300 in seven days becomes arithmetically impossible.
Timezone is the second. A rule on a custom schedule that checks at 03:00 account time with "today" as its window is reading three hours of delivery. Three hours of ROAS is noise, and noise rarely crosses a threshold in the direction you wrote.
The older advice on this SERP (recreate the rule, switch the attribution window) dates from the iOS 14.5 disruption in 2021. Try it last.
Account changes break Meta automated rules most often, because a rule's scope is frozen at the moment you save it while the account keeps moving.
Scope by selected items is the trap. If the rule applies to three named campaigns and someone duplicates one to relaunch it, the copy gets new IDs. The rule keeps watching the paused original. Everyone believes the new campaign is protected. It never was.
The level matters too. An ad set rule pauses ad sets. It cannot remove one losing product from a catalog ad set that holds forty, so it dutifully does nothing.
Then people. Every rule is created under somebody's access to the ad account. When that person leaves, open the rules list the same day and confirm their rules still show as active.
An inventory pause that stops working usually has a healthy rule and a stale input. Whatever does the pausing, the catalog's availability field or a script on your side, it reads the product feed. If the feed's last successful fetch was nine days ago, Meta still believes the sold-out jacket is in stock, and no condition has a reason to change.
So check the feed first. Read the date of the catalog data source's last successful update, then compare one sold-out product's availability in the catalog against your shop. If the catalog is wrong, the rule is innocent.
The second cause is the one from the previous section: the pause lives at ad set level while the problem lives at product level. The setup itself is in out-of-stock products in catalog ads.
You prove a Meta rule ran by reading the rule's own history of results. The campaign's numbers look the same whether the rule checked and passed or never checked at all. In Meta's rules manager, open the rule's results or activity view. The label moves between releases, so look for the list of checks, not a single "last triggered" date.
You want a check on every scheduled run, each listing the objects it evaluated. A run that evaluated zero objects is your answer: the scope is empty.
Then run a canary. Duplicate the rule, set it to notification only, and give it a condition you know is true today, such as "impressions greater than 1" on one live ad set. It should fire on its next run. If it doesn't, the problem is the rule itself or the access it runs under, and no pause was risked finding out. If it fires, the original condition is never being met: back to the guard and the window.
Yes. A safeguard needs a heartbeat. Most accounts alert when a rule acts and stay quiet when it doesn't, which is backwards for a protective rule: its whole value sits in the day it fires, and that is the day you find out it was dead.
The habit is cheap. Write down how often you expect each rule to act. A frequency pause on a prospecting account might fire weekly. If 21 days pass with no action, the absence goes on the weekly review, and somebody checks the result history before closing it. Rules that act too often have their own failure mode, which I went through in the automated rules that backfire.
This is why Adscalr logs every evaluation, including the ones where nothing fired: a logged non-trigger is what tells a quiet account from a dead rule. Rules there run on 8 metrics (CPI, CTR, hook rate, hold rate, ROAS, spend, frequency, CPM), alerts dispatch every 5 minutes, actions are pause or kill only, and a kill can be undone for 30 minutes. Full-auto is opt-in; the default is a recommendation. It does not watch your catalog or feed, so the inventory half stays yours. More on the automation layer.
This is the thinking behind Adscalr.
See the product →