Monitoring

Monitoring answers three questions: did it run, what did it do, and who asked for it.

Monitoring

The reports

Report Grain Use it for
Runs One row per step Which step failed, and why — full error text and the alerts it fired
Pipeline Executions One row per pipeline run Did the pipeline run, what triggered it, how long it took
SQL Log One row per statement sent to a database What ran, in what order, and the exact SQL — whoever sent it
Audit Trail One row per agent action What the Analyst did on your behalf, and what it cost
Transfer Usage Rolled up per org Data moved against your plan's allowance

Runs and Pipeline Executions are two views of the same activity at different altitudes. Start at Executions to see whether a pipeline ran; drop to Runs when you need to know which step inside it broke.

Runs

Filter by time window and status. Clicking a row opens the full failure context: the error class and message, raw output where available, and which notification channels fired.

Rows link through to the complete execution timeline for that job.

Pipeline Executions

Shows what triggered each run:

  • Scheduled — fired by its CRON deployment
  • API — triggered through an API deployment
  • Ad-hoc — run manually

Clicking a row opens the step-by-step timeline.

Reading a run: returned vs affected

Two row counts appear on a step and they answer different questions.

Column Means Typical
Rows returned Rows the query handed back A SELECT returns 500; an INSERT returns 0
Rows affected Rows the statement changed An INSERT of 958 shows 958; a SELECT shows —

— and 0 are deliberately different answers. 0 means the statement ran and matched nothing — an UPDATE whose WHERE found no rows, which is usually the interesting case. — means the question does not apply, or the connector does not report it: a SELECT changes nothing, and a bare CREATE TABLE creates no rows.

So a nightly load showing 0 rows affected is worth investigating, and the same load showing — is not a failure to investigate but a gap in what the database told us.

Warnings on a step

A step can finish successfully and still have something worth reading. The run detail shows warnings in amber, above any error:

  • An assertion whose policy is warn failed — the data was off, and you chose to be told rather than stopped.
  • An assertion attached to the step could not run, because it was deleted or deactivated. The gate is not being applied, and the warning says so on every run until the stale attachment is cleared.

See Assertions for what those policies mean.

Debugging a failed run

The path that answers "what broke" fastest:

  1. Pipeline Executions — confirm the pipeline ran at all, and see what triggered it. A run that never started is a deployment or schedule problem, not a SQL one.
  2. Click through to the steps. The first failed step is the one to read; the ones after it were usually skipped rather than broken.
  3. Read the error class before the message. The class says what kind of problem it is — a connection failure and a syntax error need different people.
  4. Open the resolved SQL. The step shows the query as authored, with {{variables}} intact, and the query as it actually ran with values substituted. Most "it works in QA" failures are visible in the difference.
  5. Check rows affected. A step that succeeded and changed nothing often explains a downstream failure better than that step's own error does.

SQL Log

Every statement Data Conductor sent to one of your databases in the last 30 days, newest first — from the SQL editor, the Analyst, a scheduled pipeline, or a migration. One table, so "what ran, and in what order" is a single list rather than four to reconcile.

Click any row for the SQL as it ran: after variable substitution, with values of sensitive-looking variable names masked.

Labelled by what the SQL was, not what it was called

Each row carries a kind — DDL, Query, Mixed — read from the text that actually executed, not from how the step was labelled by whoever wrote it.

That distinction is the reason the report exists. A step's declared kind is a label a person chose; it can be edited afterwards, which would change what a past run appears to have been. The SQL that reached the database cannot. So when the summary shows 38 DDL statements and 6 steps declared as migrations, the gap is real and worth a look: that is schema change running as an ordinary query — repeating on every run outside PROD, and unrecorded in the migration ledger inside it.

A banner points this out only when the two numbers disagree.

Finding things

Filter by environment, kind, and who ran it — a person, the Analyst, or a schedule. The free-text box matches the SQL itself, which is how you answer "did anyone run a DROP last week".

Classification starts from when this shipped

Older executions were recorded before the classification columns existed and show as Unclassified. Their SQL, user and timestamp are all still there — only the label is missing, and it is not backfilled because guessing at history is worse than admitting to it.

Audit Trail

The SQL Log's neighbour, and a different grain: the Analyst's tool calls, not the statements they produced. Use the SQL Log for what reached a database; use this for what the agent decided to do.

Every action the Analyst takes, joined to the session and the user who asked. The token column reports usage for the whole task an action belongs to, so several rows from one task repeat the same figure — don't sum the column.

Transfer Usage

Data moved in the last 30 days, split between pipeline data and file uploads, shown against your plan's allowance, with the pipelines consuming most. This report is informational — nothing is blocked when you go over.