How Runs Work

A Run is a single execution of an operation against a source datastore. Every operation that fires (manually, on a schedule, or via the API) is recorded as a Run on the Activity page. The Run captures who triggered the work, when it started and finished, what configuration it used, what it produced, and what its current status is. The sections below walk through the purpose a Run serves, the work that never appears as a Run, and the contexts where the Activity tab lists Runs. The components every Run exposes are on Anatomy of a Run, and the states it moves through are on Run States.

What a Run is for

A Run is the record of one operation execution, and the Activity tab is where you follow it. Whether the operation was launched by a user, a schedule, an API call, or a Flow action, it appears as a Run in the contexts it belongs to, so you can:

• Monitor what is running. The list shows every operation in flight in the current context, with its status, progress bar, phase message, and live counters (containers processed, anomalies identified, records scanned). The list updates itself while operations run; there is no need to refresh the page.
• Review what happened. Once the operation finishes, the Run keeps the outcome, with the final status, the summary metrics, the configuration it ran with, who or what triggered it, and a downloadable log. Runs stay listed until explicitly deleted, so the history of past executions remains available.
• Act on a Run. The row exposes the actions for its state. Abort stops an operation in flight, Rerun launches a fresh execution with the same configuration, and Resume continues from where a stopped Run left off, when the operation type supports it.

A Run never changes after it ends. Rerun and Resume always create a new Run; the original record stays in the list as it finished.

What does not appear as a Run

Runs are created only by the datastore operations (Sync, Profile, Scan, External Scan, Export, Materialize, and Promote). Other work the platform performs happens in the background or inline, and never shows up in the Runs list:

• Observability measurements. The daily reading that keeps the Volumetric and Freshness charts up to date runs on its own in the background. Profiles and Scans also contribute measurements, but in those cases what you see listed is the operation itself, not the measurement.
• Data catalog synchronization. Pulling metadata from or pushing it to a connected data catalog is tracked on the integration, not on the Activity tab.
• Check validation. Validating a quality check while authoring it runs immediately and shows its result in the editor; no Run is created.
• Flow executions. Flows keep their own history on the Executions tab, as noted at the top of this page.

The Activity tab

Runs live on the Activity tab, which is split into two sub-tabs:

• Runs: operations that have executed or are executing.
• Schedule: operations set to run in the future.

The same tab exists in three contexts, and the context decides whether the list holds the Runs of the whole platform, of one datastore, or of one container. Everything else carries over between them. Each context offers the same calendar heatmap above the list, showing how many operations ran on each day of the year (hover a day for the count, click it to filter the list to that day), the same search, sort, and filter controls, and the same Run rows described on Anatomy of a Run, with the progress bar, phase messages, and actions behaving identically wherever the Run is listed.

Explore context

Open Explore in the left side panel and select Activity to reach the widest scope, where the Runs of every source datastore you can view share one list. Because Runs from different datastores mix here, each row also identifies its datastore, and a selector at the top narrows the list to the datastores you care about. This is the context for platform-wide questions, such as what is running right now or which operations failed overnight, regardless of where. See the Activity page for the full walkthrough.

Datastore context

Every source datastore has its own Activity tab, holding only that datastore's Runs. The list is the same as in Explore minus the datastore controls, which the context already answers. Use it when you are working on one datastore and want its operation history without the noise of every other datastore on the platform.

Container context

Selecting a container inside a datastore narrows the scope one step further, with an Activity tab that lists only the Runs that involved that container. This is the fastest way to answer questions about a single table or file, such as when it was last profiled or scanned and how those operations ended.

See also