> ## Documentation Index
> Fetch the complete documentation index at: https://docs.minoa.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Monitor sync runs
> Check what synced, what landed where, and what needs your attention.
Once data ingestion is live, you'll spend most of your time in two places: a per-table dashboard for the data team's view, and an account-level summary inside any business case. This page walks through both.
## Per-table monitoring
Go to **Settings → Data ingestion**, open a connection, then click into a table. You'll land on three tabs.
### Runs tab
Shows the most recent sync runs for this table, newest first. Every row in the table represents one execution of the poll.
| Column | What it tells you |
| --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Started | When the run kicked off. Click to see the absolute timestamp; the relative time ("3 hours ago") sits below. |
| Duration | Total wall time. Long durations usually mean a big backfill or a slow warehouse query. |
| Status | `Completed`, `Running`, or `Failed`. Running runs that stall past 2 hours flip to `Failed` automatically. |
| Rows read | How many rows the connector pulled from your warehouse in this run. |
| Matched | Rows that resolved to a configured metric link and landed on a business case input. |
| Unmatched | Rows whose external metric ID + account didn't match any metric link. These are kept in raw staging so they can be reprocessed once a link is added. |
| Error | Failure reason if the status is `Failed` — often an auth error, schema change, or cursor regression. |
A run with **0 rows read** is normal when nothing has changed since the previous cursor. A run with **rows read but
0 matched** usually means the metric links haven't caught up with new external metric IDs — head to the Mapping
subpage to add them.
### Raw preview tab
Shows the most recently ingested rows, with the warehouse column values laid out exactly as they arrived. Use this when you want to confirm Minoa is reading the columns you think it is — for example, after editing the column mapping or pointing at a renamed source view.
The table shows `Ingested` (relative time), the deterministic `Row ID` Minoa generated, and one column per warehouse column.
### Settings tab
Three actions live here, plus the column mapping you set when you added the table.
**Trigger a sync now** — Forces a run immediately instead of waiting for the next scheduled slot. Useful for verifying a fresh credential or a new column mapping.
**Reset the cursor** — Moves the cursor backwards to a date you pick. The next run will re-read every row at or after that point. Use it when you've changed the source view's semantics, or when the cursor regressed and rows were missed.
Resetting the cursor will replay rows you've already ingested. Idempotent row hashing means duplicates won't land on
business case inputs, but the run will read more rows than usual — expect a slower run.
**Disable the table** — Stops scheduled polls for this table. Already-ingested values stay on business cases; only future syncs are paused.
## Mapping audit
When a value isn't showing up where you expected, the fastest path through is the **Mapping** subpage's audit drawer.
1. Open **Settings → Data ingestion → Mapping**.
2. Click the metric link in question.
3. The drawer shows recent rows from raw staging that match this `(external metric ID, account)` pair — including ones that failed validation — so you can see exactly what Minoa is reading.
If the drawer shows rows but the input still doesn't update, the issue is usually downstream: the input might not be in timeseries mode in the business case, or the sync might not be turned on for that scenario. See [Use ingested data in a business case](/pages/integrations/data-platforms/using-in-business-case).
## Account-level runs (from inside a business case)
Anyone working on a business case can see recent syncs for that account. Open the **Data** icon in the BC's left rail, then click **Open full view**. The canvas shows an "Account runs" table with the run timestamp and the number of metrics seen in each run.
This is useful when the data team has set everything up and you just want to know whether fresh data has arrived for your deal.
## Troubleshooting common failures
Credentials have expired or been rotated outside Minoa. Update the connection from **Settings → Data
ingestion**, paste the new credentials, run **Test connection**, and save.
The source view's schema changed and one of the mapped columns no longer exists. Open the table's **Settings**
tab, re-pick the affected column from the dropdown, and save. The next run will use the new mapping.
The cursor column isn't strictly monotonic, so Minoa never advances past a stable watermark. Check the view's
`cursor_ts` definition: it should never regress for a given `(account, metric)` pair. Patch the view, then
trigger a sync to confirm the run completes with the expected delta.
Two checks: (1) is the input in timeseries mode for the right scenario? (2) is data ingestion turned on for that
scenario in the business case? See [Use ingested data in a business
case](/pages/integrations/data-platforms/using-in-business-case). If both are correct, open the Mapping audit
drawer to confirm the metric link is pointing at the input you expect.
The connector is reading rows but no metric link routes them. Open the Mapping subpage and look for external
metric IDs without an input mapped — those are your culprits. Once linked, the rows reprocess on the next run
automatically.