Inspecting run items
A run item is the per-resource breakdown. One run with three enabled resources has three run items. Each item carries everything you need to understand what happened to that resource in that run.
The run detail page
Open a run and the page is laid out the same way every time:
- A progress summary at the top — what the run is doing right now, and how much of your data has reached the destination.
- Resources — the run items, one row per resource. This is where the per-resource detail below lives.
- Errors — every failed row across the run, with its count in the tab label.
- Log — the run’s event stream, live while the run is going.
- Configuration — what this run was asked to do: its phases, options, the mapping version pinned per resource, and a per-step breakdown for when you need to see how far each step got.
Reading the progress bar
Progress answers one question: how much of your data reached the destination? Not how far along a step is. Each resource gets a bar covering all of its records, split into:
| Segment | Meaning |
|---|---|
| Loaded | The record is in the destination store. |
| Failed | The record could not be created or updated. |
| Up to date | Nothing to do — the record is already there and unchanged. |
| Not yet reached | Still outstanding. |
The four always add up to the resource’s record count, and the percentage is the share that reached the destination. That means a resource that has been extracted and transformed but not yet loaded shows 0% — its data hasn’t arrived yet. Progress only reaches 100% when every record has actually landed.
On a run that stops before the load step — an extract-only or transform-only run — the bar measures that step’s output instead, so 100% still means “the run did everything you asked it to.” An extract-only run shows that it is still counting until the fetch finishes, because until then “how many were fetched” and “how many there are to fetch” are the same number and a percentage would be meaningless.
On a dry run nothing is written to the destination, so the bar counts the records the run cleared to load and labels them that way. It is a measure of what a real run would attempt, not of anything that landed.
Reading the steps
Alongside the bar, each resource shows the steps it goes through — Extract → Transform → Load — and which one it is on. Steps are marked done, in progress, failed, or stalled. Resources run independently, so one can be loading while another is still transforming.
The steps tell you where the work is. The bar tells you how much is done. They are deliberately separate, because being finished with a step is not the same as being finished.
What else you see on a run item
| Field | Meaning |
|---|---|
| Records | How many records this resource has to move. |
| Started / finished | Wall-clock time and duration. |
| Errors | A list of per-row errors with the source ID, the step that broke, and the error text. |
| Mapping version | The version pinned at the start of this run for this resource. |
When a run stops making progress
If a step has been running without moving for more than ten minutes, the run is marked Stalled and the page tells you how long it has been still. A stalled run will usually not recover on its own — cancel it and start a new one. Records that already landed stay where they are, and the next run picks up from there.
Only a run that is still going can be stalled. A run you cancelled reads Canceled, and the step it was on reads canceled too — it never sits there looking like it is still working.
Reading errors
Errors are per-row, not per-run. A typical failed run item shows something like:
errored: 12 of 4,317Click through to see the twelve specific source IDs, the phase each broke in, and the error message Shopify (or JSONata, or the source API) returned. From there you can:
- Click the source ID to see the original source row.
- Click the staged record to see the payload that was rejected.
- Open the mapping at the version pinned to this run and trace why the output was wrong.
Counts that don’t add up
A few things to know:
- Transformed ≤ extracted — some rows may produce no output if the mapping returns nothing for them.
- Up to date covers records skipped because they haven’t changed since the last load, and records left alone by the skip conflict strategy.
- If you re-run a migration where nothing has changed, expect a bar that is almost entirely “up to date” — that is a healthy result, not a stalled one.
- Records that failed are never counted as up to date. A record that broke in the transform step is shown as failed and nothing else; the four parts of the bar always add up to the total.
- A resource with no records at all reports zero rather than staying on “still counting”. If a resource stopped before its records could be counted — a fetch that failed outright — the run says so rather than leaving the whole total unknown.
Long-running items
While a large catalog is in flight the numbers update live. Until the extract step finishes, the total isn’t known yet — Graftport doesn’t know how many rows the source holds until it has finished asking — so the bar shows that it is still counting rather than guessing a percentage. Once the record count is known, the bar becomes a real measure of time-to-finish.
The Configuration tab keeps a per-step breakdown for when you need it: how far each of Extract, Transform and Load got, with its own count, error tally and duration. Runs from before per-step progress was recorded have no breakdown to show; the tab says so, and those runs show each resource’s final state in the Resources tab instead. That is a debugging view — it tells you where a run is stuck, not how much of your data has landed.