Run history
See every time an automation fired, what it decided, and why — including the orders it deliberately skipped.
Every time an automation is evaluated, Stork Credit records a run. A run exists whether or not credit was issued, which makes run history the first place to look when a rule didn't do what you expected.
Open an automation from the Automations list and click the Runs tab.
Run statuses
In progress
The run is currently being evaluated
Completed
Criteria were met and credit was issued
Skipped
The rule was evaluated but a condition wasn't met — nothing was credited
Failed
Criteria were met, but the credit could not be issued
Skipped is normal. An order-value rule is evaluated against every paid order, so a rule targeting a segment produces a skipped run for every order from outside it. Skipped runs are a record of a decision, not an error.
Reading a run
Each run shows the order or campaign it relates to, the customer, and the credit value. Skipped and failed runs also show the reason directly on the row — for example No thresholds crossed or Customers not seeded — so you can scan the list without opening each one.
Common skip reasons and what they mean:
Not within active period
The order fell outside the rule's start/end dates
Customer not eligible
The customer isn't in the targeted segment or list
Customer doesn't have a matching tag
The rule targets customer tags and the customer carries none of them
No customer on order
The rule targets specific customers and the order has no customer
Customer already rewarded by this rule (once per customer)
The rule is set to Once per customer and this customer has already been credited by it
No qualifying line items
Nothing on the order matched the rule's products or collections
Minimum requirements not met
The order was below the minimum amount or quantity
Order total exceeds maximum purchase amount
The order was above the maximum
Store credit value is 0
The calculation produced nothing to issue
Best-value only: another promotion has a higher value
Stacking is off and a different rule won — see Promotion stacking
Best-value only: another promotion already credited this order
Stacking is off and a different rule had already credited this order, for example before a referral code was entered on the Thank you page
Already credited for this order
This rule had already credited the order, so nothing was issued twice
And the failure reasons:
No customer ID found
The order had no customer account, so there was nothing to credit
Failed to credit store credit
Shopify rejected the transaction — the message from Shopify is in the log
Runs from the Thank you page
When a shopper enters a referral code on the Thank you page after their order is paid, Stork Credit runs your referral reward rules again for that order. These runs are marked Referral code entered on the Thank you page, so you can tell them apart from runs started by the order being paid.
Run logs
Open a run to see its log: a step-by-step record of the evaluation, including the numbers used at each check. A percentage calculation logs its base and result, so you can confirm exactly which order value the reward was taken from:
Minimum and maximum checks log the same way, showing the compared values and the outcome.
When a rule sends the Store Credit Alert email, the log records each email sent. If the customer got Shopify's store credit email instead, a warning explains why, for example because your email allowance ran out. If an alert failed to send after the credit was issued, the log shows an error. The run is still Completed, because the credit was issued.
Filtering
The runs list can be filtered by status and searched, which is the quickest way to answer "did this ever actually pay out?" — filter to Completed and look at the count.
Scheduled automation runs
A scheduled rule produces one run per execution, covering all its recipients rather than one run per customer. The run records how many customers were resolved, credited, and failed, plus the amount per customer. Individual failures appear in the log with the customer's email address.
Threshold automation runs
A threshold rule produces one run per execution. The run records how many customers were checked, how many were credited, and how many thresholds were passed in total — a single customer can account for more than one if they jumped several at once.
Activating a rule produces its own run, marked as recording customers rather than crediting them. It shows how many existing customers were recorded at their current spend, and issues no credit. If you deactivate and reactivate a rule — or run Retry seeding from Settings — the new run is marked Re-seed to distinguish it from the first one. A re-baseline from Settings produces the same kind of run, marked as re-baselined.
While a recording or re-baseline run is in progress, its row updates as it goes — "recorded 800 of 3,200 · recording…" — so you can watch a large store's backfill without refreshing. Opening the run shows the same progress in its log.
A run is skipped when nobody has passed a new threshold since the last run, which is the normal state most days. A run is also skipped if the rule's customers have not been recorded yet — this normally sorts itself out within a few minutes of activation. If it doesn't, use Settings → Retry seeding.
If a customer is credited but their progress cannot be saved, the run log records it as an error, and that customer may be credited again on the next run.
When credit is held
A threshold rule with a hold turned on produces two runs for each batch of rewards.
The first records how many rewards were held rather than issued, and when they are due to be released. No credit has been issued at this point, so the run shows a credit total of zero.
The second appears when the wait is over, and records how many held rewards were released, how many were cancelled after a refund, and how many were reduced because the customer fell back past some — but not all — of the thresholds they had passed. Its credit total is what was actually issued.
If a customer's lifetime spend cannot be read when the wait is over, their reward stays held and is tried again on the next check rather than being issued unverified.
Last updated