The Check step at the bottom of the rule editor replays the last 30 days of reviews through your trigger and tells you what it would have caught. It changes nothing: nothing is replied to or changed by running it.
What you need: a trigger with something to match. On a keyword trigger the button waits until you add a keyword, and on a site trigger until you pick a site, because there is nothing to test.
Run it
- Finish the When step, and set Where if you want the test scoped to particular sources.
- Press Run backtest.
- Read the headline: how many reviews it would have matched in the last 30 days.
A finished backtest showing the match count, 4 weekly bars and the sources the matches came from.
The same check is on every rule row as Preview matches, for a rule that is already saved.
Reading the result
The weekly bars split the matches across the last 4 weeks, labeled "4 weeks ago" through "last 7 days". A flat line means steady volume. A single tall bar usually means one busy week, such as a launch or a bad day, and a rule tuned to that week may sit idle afterward.
The source counts show where the matches came from. If one source carries nearly all of them, consider scoping the rule to it rather than running it everywhere.
The sample reviews are the part worth your attention. Read them as the customer who wrote them. If a complaint is sitting in a list you were about to answer with a cheerful thank-you, the trigger is wrong.
When nothing matches
"Nothing matched, and nothing broke" is a real answer, not an error.
- On a keyword trigger it means no review in the last 30 days contained those words. Widen them, or add the wording people actually use, then run it again.
- On any other trigger it means the rule is safe to switch on, it will not do much yet.
When the result goes stale
Edit the trigger or the scope after a run and a banner appears over the result: the numbers describe the rule as it was when you pressed the button, not the rule you have now.
The backtest result marked as out of date after the trigger was edited.
Run it again. A stale result is the easiest way to talk yourself into switching on a rule you have not actually tested.
What a backtest cannot tell you
- It tests the trigger and the scope, not the actions. It says which reviews would have been caught. It does not say whether your reply reads well under them.
- It cannot see reviews we never collected. A source connected last week has less than 30 days to test against.
- A disconnected source shows as "Disconnected source" in the breakdown. Its reviews still count, because you still hold them, but the rule cannot act on that source until it is reconnected.
- It does not test the suspicious trigger's timing. A burst is judged as reviews arrive, so the live rule is the real test there.
- It says nothing about volume ahead. 30 quiet days do not predict the day a local news story sends you 40 reviews.
The second safety net
A backtest is a read. Trial mode is a live run with the hands tied: the rule matches real reviews as they arrive and records each match, and nothing is replied to, assigned or sent. The row carries a Trial badge and its counter reads "Would have fired" and a count.
Use both. Backtest to catch a badly built trigger in seconds, then leave the rule in trial mode for a week to see what real reviews do to it.
What this costs
Nothing. A backtest reads reviews you already have, and trial mode never acts, so neither spends a credit. Only a live action costs, 1 per action.