Sync history

Sync history shows you what a data source actually did each time it ran, how many rows it read, how many it matched and how many it changed.

Sync history tells you what one of your data sources actually did, run by run. Every time a source goes and fetches your supplier’s file, it leaves you a line here. That line has the numbers from that run: how many rows your file had, how many of them found a record in your catalog, and how many of those went in.

You open it for one of three reasons. A run tells you it worked and you cannot see any difference in your catalog. A supplier’s numbers have stopped arriving with no warning. Or one of your products is not picking up its price and you need the reason for that single row.

You will find it on your data sources list. Go to Uploads, select the Data Sources tab, and click History in the Actions column at the right end of a source’s row. A dialog opens over the page with a table of that source’s runs, newest at the top, going back to its very first one.

One thing shapes everything you see in there: a single run leaves you two lines, not one. Download is the trip to your supplier’s file. Mapping is the writing into your catalog. They can fail separately, so you get them counted separately, and a dropdown at the top of the dialog is how you move between them.

Before you start

What your role lets you do

Sync history is inside the Data Sources tab, and that tab is Manager and above. If you are an Admin or a Manager you can open the history of any source, download the file a run read, and download its row-by-row report.

An Editor does not see the tab at all, so there is nothing here to open. You set roles in team, roles and permissions.

The detail behind a run does not last

So a report you might need later is one you download while it is still there. Once you have downloaded a report it keeps working for you after that, which the section on it explains.

How to read a run

1. 1

   Open sync history

   From Uploads, select the Data Sources tab and find your source in the table. Click History in the Actions column at the right end of its row.

2. 2

   Pick the phase you care about

   The dropdown next to the dialog title says Download or Mapping. Leave it on Download to see what arrived from your supplier. Switch it to Mapping to see what got into your catalog.

3. 3

   Find the run

   Your runs are listed newest first, and the Started column says how long ago each one began. Click a column header to sort by that column instead.

4. 4

   Read the status and the counters

   The Status column says how that phase ended. Every column after it counts rows. Hover a column header and a short line tells you what that column counts.

5. 5

   Open the detail

   On a Mapping line, click Results in the Actions column for a report with one row per record. On a Download line, click Download file for the file your supplier sent.

That is the whole screen. A Completed status, with numbers in the columns you expected, is a run that went fine and you can close the dialog.

Everything below explains the two phases, every counter on each of them, and the two downloads. You do not need any of it to see whether your run worked.

Every option in detail

The two lines every run leaves

You get one line per phase because the two phases can fail separately. Download goes out to your supplier, reads the file, and stores its rows. Mapping takes those stored rows, finds the record in your catalog each one is about, and writes your values into it.

The order between them is fixed, which is why you sometimes get only one line. You only ever get a mapping line because a download line put rows in front of it.

That last row is what a healthy quiet feed looks like, and it is worth knowing before you go looking for a problem. Nothing changed, so nothing was counted for you.

Switching between the two phases

The dropdown is next to the dialog title, at the top of the dialog. Download and Mapping are its two choices, and each one gives you its own table with its own columns.

Each side also keeps your sorting, your filtering and your page separately. A filter you set on Download does not follow you across to Mapping, so switching sides never hides rows you did not mean to hide.

The phase is part of the page address behind the dialog. Copy that address while you are looking at Mapping and whoever you send it to opens on Mapping too.

The three columns both sides share

Whichever phase your dropdown is on, your table opens with the same three columns.

Every other column on either side counts rows, and the two sides count different things.

You see a dash instead of a zero in all of those counting columns. So a cell with a number in it is always something that really happened to your rows. A line of dashes is a quiet run and not a broken one.

What the download counters count

On the Download side of the dropdown, these five columns count rows in your supplier’s file. Nothing on this side has looked at your catalog yet.

You get Removed once, on the run where those rows stopped arriving, and then it goes back to nothing. A source that lost 400 of your rows last week shows you nothing today. What happens to the products themselves is in data sources.

There is no Errors column on this side. A download either worked or it did not. When it did not, you get the reason as a sentence on the Status badge instead of a number in a column. Errors on single rows are counted for you on the other side.

What the mapping counters count

On the Mapping side, two of the columns are running totals and everything else is only about this run. That is the most misread thing on the screen, so it is worth reading twice. Matched and Unmatched tell you how much of your feed has a record in your catalog today, counted across every run there has ever been. Neither of them describes the work this run did.

Lost is the column to watch. Rows that pointed at one of your products no longer do. Those products have stopped getting this supplier’s numbers, and nothing else on this screen will tell you that.

A run with warnings and no errors is Completed, not Partial. A warning means your write went through and one part of the row could not be used, like a brand name your catalog does not have. Your record still got everything else in that row.

Sorting, filtering and searching the runs

Four text buttons are above the table. They work the same for you on both sides.

You can sort and filter on every column, and clicking a column header sorts by it. On a counting column your condition takes a number. Set Errors to greater than (>) and 0 and you keep every run that failed a row. Set it to equals (=) and 0 instead and you get the runs that failed none, which is what the dash in that column stands for.

The Status condition is a dropdown, and it lists only the statuses this source has actually had. A short list is normal and does not mean you are missing anything.

You get 50 runs at a time, and the footer under the table gives you 25 or 100 instead.

Downloading the file a run read

Download file, in the Actions column of a Download line, gives back your supplier’s file exactly as that run received it. There is no format for you to pick, because it is the file your supplier sent.

Your file arrives named after the moment the run started, like feed_2026-08-04-14-30-05.csv. Open it when a run counted something you did not expect and you want to see what actually turned up.

Two cases leave the button inactive, and hovering it tells you which one you are in. While the run is still going there is nothing to hand you yet. More than 30 days after the run your saved copy is gone, and the message points you at Run now on the source’s row to fetch a fresh file.

Asking for the row-by-row report

Results, in the Actions column of a Mapping line, builds you a report with one row per record that run looked at. It is the only place a run explains itself record by record. Open it when a counter tells you something failed and you need to know which of your rows it was.

Clicking it opens a small dialog called Select file format with two cards, CSV and Excel. Pick one and your report starts building.

Building takes a moment and the dialog says so. You can close it: closing cancels nothing, and your download starts on its own when the report is ready. If it takes longer than 2 minutes you get a message asking you to try again shortly. Your report keeps building in the meantime, so clicking Results again a little later usually gives it to you at once.

A report you have already asked for is kept. It is built once and stored, so asking again gives you the same file with no wait. So a report you pulled inside the 30 days keeps downloading for you long after the detail behind it has gone.

The button is inactive on a run that is still going, and on a run that looked at no records at all. Hovering it tells you which.

Limits

What sync history cannot do

What the numbers are telling you

Why the counters do not add up to your file

On the Download side, you get New, Updated and Unchanged adding up to File Rows only when your supplier’s file repeated nothing and every row saved.

Two rows with the same values in every column this source reads count as one row, and the later of the two is the one kept. So a file that spreads one of your products across several rows shows you a gap on a run that went perfectly.

Removed stays outside that sum, so never add it in. It counts products that stopped arriving, not rows that did.

The other reason for a gap is rows that failed to save. That one turns your run Partial.

Why a settled feed shows almost nothing

Every run walks every row that has a record in your catalog, not only the rows that changed. Your counters, though, only count the rows the run had something to say about.

A row whose values still agree with your catalog, and whose last outcome matched this one, is checked and then left out of your counts completely. It is left out of your Results report too. So a settled feed of 60,000 rows shows you a handful of numbers, and that is your feed working rather than your feed stopping. What each run checks is in data sources.

When a success hides a dropped field

Knowing why lets you work out the next case yourself. One variant’s row would otherwise rewrite your shared product on behalf of all its siblings. A row about your red small shirt would be setting the title, the description and the categories for your blue large one too.

Images are the exception. Primary Image URL and Gallery Image URLs go to the variant that matched instead of being dropped. A blank cell there wipes the images of that one variant and of no one else.

So a feed you mean to own a product’s shared fields has to match at product level, on Slug or Title. A feed matching on a SKU or a barcode is a per-variant feed whatever else you put in its columns, and data sources covers which of your rules match which way.

What is inside the Results file

The report Results builds you, from a Mapping line, has one row per record that run looked at. Its columns are built out of the run itself, and they come out in this order.

Your own match columns are the reason to open this file on a row that found nothing. The screen tells you a row did not match. Your file shows you the value the run actually compared, which is usually your answer. A SKU with a space in it, an empty cell, a code your supplier changed without telling you.

match and result answer two different questions, and reading them together is what makes your file worth opening. A row can be existing and error, so it kept its record and your write failed. A row can be new and success, which is your normal good case.

The screen’s Not Matched count and its Lost count both appear in your file as a result of not_matched. The match column is what separates them for you.

Your report’s own column names are always in English, and so are the values in match and result. Your own columns keep the names your supplier’s file gave them.

When something goes wrong

What each status means

The Status column is the first one on both sides, and it has one of four words in it.

What separates Partial from Failed is whether anything at all got through. On the download side, whether any of your rows were stored. On the mapping side, whether any of your records were written. Nothing at all is Failed.

Partial is a healthy run. Your file arrived and the machinery worked, and some rows inside it did not. It does not count toward your source switching itself off, which data sources covers from the health side.

Finding out why a run failed

Hover the Status badge on a Failed line and a sentence tells you why. That sentence is your whole explanation, and there is no second place to look for it.

When a run never finishes

A line does not stay on Running forever. A phase that stops moving for 30 minutes is closed as Failed for you, with a message on the chip saying it made no progress. Your source is started again by its next scheduled run.

That matters more than it sounds, because Run now on the source’s row is inactive while a run is going. A run that died halfway would otherwise keep your button disabled until you noticed.

When Results or Download file will not work

Both buttons are in the Actions column at the right end of a line, and both of them go quiet on you in more than one case.

Two things that happen with no message

Nothing on screen tells you about either of these, so they are worth knowing about.

Your Results report stops at 50,000 rows. A run that looked at more of your records than that gives you the first 50,000 and no note saying it stopped.

And a row that matched one variant of a product with several variants loses the product’s shared fields, and still counts under Success for you.

Where to go next