Background Jobs and Status

A vs B does a fair amount of work for you in the background: mostly overnight, so your store data is fresh each morning without you lifting a finger. This page explains, in plain terms, what those jobs are, where to watch them, and how you find out if one of them has a problem.

The guiding rule: nothing fails silently. If a background job breaks or does not run, you will see it in three places: a red banner in the app, a status label on the affected screen, and a plain-language email by 8am. You never have to go hunting.

The jobs A vs B runs for you

Job	What it does	How often
Catalog feed sync	Fetches your product feed and keeps the Live Catalog current.	Every hour
Product cost sync	Pulls each product's unit cost from Shopify so profit figures are right.	Every night
Recommendation run	Rebuilds your recommendation lists from the latest orders and views.	Every night
Order profit calculation	Works out the profit on recent orders using the freshest costs.	Every night
Visitor profile refresh	Refreshes what each shopper tends to buy, for smarter targeting.	Every night
Dataset cleanup	Tidies away old, unused data files to keep storage lean.	Every night
Catalog import	The one-off bulk load when you first connect a store.	When you connect
Privacy requests	Erases, exports, or purges a shopper's data when asked.	On request

You do not schedule or trigger any of these by hand (apart from a manual "Sync now" if you want one). They run on their own.

Where to see live status

On the Commerce hub. The hub shows a health summary that reads simply "healthy" when nothing failed or stalled in the last 24 hours.

The Commerce hub page with a healthy status line reading that nothing failed or stalled in the last 24 hours

This line turns into a list of what needs attention as soon as anything fails or stalls.

On every Commerce page. A red banner appears at the top of every Commerce page (not just the hub) the moment a job fails, stalls, or misses its schedule, and disappears again once things are healthy.

On each screen. Every commerce screen shows a small status label next to the thing it is about:

Queued: waiting to start.
Running: in progress. If the job knows how much is left, you will see a percentage (for example, "Running 60%"); if it cannot know yet, it simply says "Running…".
Succeeded: finished cleanly.
Failed: something went wrong. The screen shows a short, plain explanation of what happened, never a blank space.
Canceled: you stopped it (see below). It did not finish, and it did not fail.

The Background work table listing jobs with their status badges, durations, and timestamps

Each job's Status badge shows Queued, Running, Succeeded, or Failed.

The status updates on its own while you watch: you do not need to refresh.

Recipe runs you start yourself

When you press Run now on a recipe, the run goes straight to the recommendation engine instead of into the table above. You can still follow it:

The Background work page lists it in a Recommendation runs box above the table while it is queued or running. If it fails, it stays there with the reason written out.
The Last run column on the Recommendations page shows the same status, and so does the recipe's own page: Queued, Failed with the reason, or the result.
If the engine has not answered 30 minutes after you pressed Run now, the run is shown as Failed and says so. Press Run now again; if it keeps happening, contact support.

Stopping a job that is still running

The Background work table has an Actions column. Any job still Queued or Running shows a Cancel button there, and asks you to confirm before it does anything. Finished jobs show no Cancel button: there is nothing left to stop.

Cancelling is a request, not a switch. The job finishes the piece of work it is part-way through, notices it has been cancelled, and stops there. Anything it had already written stays written. The row then reads Canceled, with the reason recorded against it.

Two things worth knowing:

If the job happens to finish in the moment between you clicking and the request landing, A vs B tells you it was too late and refreshes the row rather than pretending the cancel worked.
Cancelling frees the slot straight away, so a job of the same type can start again as soon as it is due. If the job was one of the nightly ones, the next night's run picks it up as normal.

What a failure looks like

Say a recommendation run for one of your projects hits a snag overnight. Here is exactly what happens:

That one project's job is marked Failed. Because each project runs on its own, one project's problem never stops the others: every other project's jobs finish normally.
The Commerce hub turns red and the recommendations screen for that project shows the failure inline, with a short reason.
You get one email by 8am (see below).

Nothing is hidden, and nothing is left half-done without a record.

The cost-sync safety check

Profit figures are only trustworthy if the underlying costs are fresh. So the nightly Order profit calculation waits for that night's Product cost sync to finish first. If the costs are not ready, A vs B skips the profit run rather than pricing against stale costs, with the reason "Cost sync has not completed for today, so the profit run was deferred to avoid pricing against stale costs."

That is expected, self-correcting behaviour, not a broken job, and A vs B treats it that way: a single night's wait is not counted as a failure and does not appear in your morning email. If the wait carries on for a second night, the email tells you, because by then the real problem is upstream: check why the cost sync itself is not completing (for example, a Shopify connection that needs reconnecting). You will never see profit numbers quietly calculated from yesterday's costs.

The morning email

If something in your workspace needs a look, A vs B sends one email per workspace, by 8am, to the people who manage projects (owners and admins). It is written in plain language and groups the trouble under three headings:

Failed: jobs that ran but broke, each with a short reason and a View link straight to the affected screen.
Has not run: a scheduled job that has produced no result for longer than expected. Each one names which project it affects, when it last completed and how many nights ago, and how often it is meant to run.
Waiting: an Order profit calculation that has been waiting on Product cost sync for more than one night.

Three things about when it arrives:

It is about your projects, not ours. If the problem is on A vs B's own side, it goes to the A vs B team to fix. You are told about the jobs for your own projects, which are the ones you can do something about.
The same problem is not repeated every morning. You get an email when something starts going wrong, and then a weekly reminder for as long as it stays wrong. If anything new breaks, the email arrives that morning rather than waiting for the reminder.
A quiet project is not a broken one. Some of the nightly jobs only have work to do for stores with recent orders. If a store has gone quiet, its jobs are skipped with nothing to do, and A vs B does not report that as a failure.

If nothing needs a look, you get no email: silence means healthy. And if the checker that sends this email ever stops running itself, our own system health monitor flags it, so the safety net is always watched.

What to do when you see a failure

Most failures are transient (a slow response from Shopify, a brief network blip) and A vs B retries on its own. A job that is still Failed the next morning is worth a look:

Open the screen from the email's View link (or the red banner).
Read the short reason shown inline.
If it points to a connection problem (for example, a store that needs reconnecting), fix that, then use Sync now or Re-sync if the screen offers it: otherwise the next nightly run will retry automatically.

Catalog Management and Health: the product-catalog health view.
Orders and Attribution Health: order and revenue freshness.
Snippet Reliability: how the on-page snippet degrades gracefully on a slow network.