Skip to main content

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.

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.
ColumnWhat it tells you
StartedWhen the run kicked off. Click to see the absolute timestamp; the relative time (“3 hours ago”) sits below.
DurationTotal wall time. Long durations usually mean a big backfill or a slow warehouse query.
StatusCompleted, Running, or Failed. Running runs that stall past 2 hours flip to Failed automatically.
Rows readHow many rows the connector pulled from your warehouse in this run.
MatchedRows that resolved to a configured metric link and landed on a business case input.
UnmatchedRows 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.
ErrorFailure 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.

​
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. 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.