Executions

Purpose#

Every family in Abrq DIP keeps its own run history: CDC has its runs, streams have theirs, so do file ingestions, email feeds, ETL tasks, jobs and exports. That is the right place to investigate a single pipeline, and the wrong place to answer "what broke last night?"

/executions is the answer to that second question. It is a single, read-only monitor that aggregates runs from every family into one list, with one status vocabulary and one set of filters.

Use it as the morning check: filter to failures, scan the families, then drill into whichever run needs a person.

Note. Executions is read-only. It shows you runs and lets you download diagnostics for a failed one; it does not start, cancel, or retry anything. Those actions live on each family's own page, which is where the context is.

Before you begin#

Role. Any authenticated user can open Executions and read its runs and failure summary. There is no separate capability, and no editor requirement — it exposes nothing that the individual family pages do not already show.
Project-scoped ETL runs still obey project visibility. You see what your memberships and global role let you see.

Read the run list#

Open /executions. The list refreshes on its own every few seconds, so a page left open acts as a live monitor.

Each row is one run: its family, the resource that ran, the status, when it started and ended, and the row counts where the family reports them.

Filter by family#

Runs are tagged with a kind. The kinds are:

Kind	What it covers
`cdc`	Change-data-capture runs
`stream`	API-pull stream runs
`file`	File ingestion runs
`email`	Email feed runs
`etl_task`	SQL Pipelines task runs
`etl_job`	Job runs (the orchestration layer)
`export`	Data export runs
`conn_test`	Connection tests
`connector`	Connector-level activity

Kind is a multi-select: pick as many as you want and the list narrows to their union. Picking none shows everything.

conn_test is worth calling out. Connection tests are runs like any other, so a connector that has started failing its tests shows up in the same timeline as the pipelines that depend on it — often before those pipelines fail themselves.

Filter by status#

The status vocabulary is normalised across families, so success means the same thing whether it came from CDC or from an ETL task:

Status	Meaning
`queued`	Accepted, waiting for a worker.
`running`	In progress.
`success`	Completed, nothing rejected.
`partial`	Completed, but some rows or units were rejected or skipped. Worth reading.
`failed`	Ended in error.
`cancelled`	Stopped deliberately.
`skipped`	Not executed — typically because a precondition was not met.

Tip. partial is the status people miss. A run that finishes partial is green enough to be ignored and red enough to matter — it usually means quarantined rows or rejected records. Filter to partial once a week.

You filter by one status at a time.

Filter by time window#

The list covers a rolling window, measured in hours and defaulting to 168 hours (seven days). The window can be widened up to 2160 hours (90 days) or narrowed to a single hour.

The list is also capped: it returns at most 500 runs, defaulting to 200. A busy deployment can hit that cap, so a quiet-looking list on a wide window may simply be truncated — narrow the window or the kinds rather than concluding nothing happened.

Read the failure summary#

The failure summary answers "what is going wrong right now" over the last 24 hours by default (the window is adjustable).

It reports:

Field	Meaning
Total runs	How many runs happened in the window.
Total failed	How many ended in failure.
Total rejected rows	Rows rejected across those runs — the data-loss number, not the run-count number.
By source	The same totals broken down per family, so you can see whether the failures cluster in one place.

The by-source breakdown is what turns a number into an action. Twelve failures spread evenly across six families usually means an infrastructure problem — credentials, network, a database restart. Twelve failures all in etl_task usually means someone changed a table.

Tip. Read total rejected rows alongside total failed. A deployment with zero failed runs and forty thousand rejected rows is not healthy; it is quarantining at scale. See SQL pipelines.

Drill through to run detail#

Executions is a routing surface, not a terminus. Click a run to open the run detail on the family that owns it:

Kind	Where it takes you
`cdc`	CDC run detail
`stream`	Streams run detail
`file`	File ingestions run detail
`email`	Email feeds run detail
`etl_task`	SQL pipelines task run — logs, metrics, quarantined rows
`etl_job`	Jobs run — the per-task run breakdown
`export`	Exports run detail

That is where the full log, the per-family metrics, and the actions (cancel, retry, replay quarantine) live.

For a failed run, Executions also offers a diagnostics download directly from the row — a bundle you can attach to a support conversation without first finding the right family page.

Field reference#

Run list filters#

Filter	Values	Default
Kind	`cdc`, `stream`, `file`, `email`, `etl_task`, `etl_job`, `export`, `conn_test`, `connector` — multi-select	none (all)
Status	`queued`, `running`, `success`, `partial`, `failed`, `cancelled`, `skipped` — one at a time	none (all)
Time window	1 to 2160 hours	168 hours
Limit	1 to 500 runs	200

Failure summary#

Filter	Values	Default
Time window	hours	24 hours

Failure modes#

What you see	Cause	Fix
A run you know happened is absent	It falls outside the time window, or the list hit its result cap.	Widen the window, or narrow the kinds so the cap is not reached.
Fewer runs than expected across the board	The result limit truncated the list.	Filter by kind or status; the cap applies after filtering.
Runs from a project you expect are missing	You are not a member of that project and your global role does not grant broad read.	Ask an Owner for membership — see RBAC.
No cancel or retry button anywhere	Expected. Executions is read-only.	Open the run on its family page and act there.
A wave of `conn_test` failures for one connector	The connector's credentials, network path or target database changed.	Re-test the connector — see Data connectors.
Everything reads `queued` and nothing progresses	Background workers are not consuming the queue.	Check background processing with your platform administrator — see Background processing.
Many runs `skipped`	A precondition was not met — commonly a disabled resource or an unmet dependency.	Open one run's detail; the owning family records the reason.