Pipeline in the dashboard

The Pipeline section of the sidebar is the operational view of metric computation. On a schedule, Traffical runs SQL against your warehouse — extracting assignments and facts, computing metric results, rolling up dashboards, and evaluating policy health. Use these pages to verify the pipeline is running, spot failures, and see how fresh your numbers are. The section has three pages: Definitions (where the SQL is authored — see Definitions), Workflow Runs, and Data Freshness. This page covers the last two. If your project has no active definitions or running policies, these pages are mostly empty — there’s nothing to compute yet.

​

What runs

Every execution appears as a workflow run with a type:

​

Workflow Runs

The Workflow Runs page lists recent executions, newest first, with a duration chart across the top. Filter by type or status, or search by run id. Each row shows the run id, workflow type, trigger (scheduled, manual, API, or restart), start time, duration, and status:

• queued / running — in progress; running rows are highlighted (click Refresh to update the list — the run detail page updates live)
• succeeded — everything completed
• partial — some of the run’s work succeeded and some failed; the failures don’t block the rest
• failed — the run errored
• cancelled / terminated — stopped before completing

A definition that keeps failing doesn’t stall the whole pipeline — other definitions keep computing, and the run lands as partial.

​

Run detail

Click a run to drill in. The header shows trigger, duration, and start/end times. Below it:

• Spec — what the run was asked to do, with links to the policies, metrics, and definitions involved
• Steps — the execution broken into setup, extract, compute, and finalize steps, each with duration, rows processed, attempt count, and status. Sub-steps expand inline; failed steps expand automatically with their error.
• Output — run-level results, again linked to the entities they touched

Steps that executed SQL have a viewer: click the step’s SQL icon to open the rendered query (template variables already substituted), formatted and copyable. Paste it into your warehouse’s own console to reproduce a failure or check what was scanned — the fastest way to debug a broken definition. While a run is live, the page polls every few seconds, so you can watch steps complete.

​

Restart, terminate, trigger again

From the run detail page:

• Terminate stops a running run. In-flight work is abandoned and the run is marked terminated.
• Restart re-runs a finished run from a step you choose — useful when a late step failed and the earlier extraction was fine.
• Trigger again opens the trigger dialog pre-filled with the same workflow type.

​

Manual runs

Click Trigger run on the Workflow Runs page to start a run by hand. Pick a workflow type; each exposes a small set of options — for example, an analysis run can be lite (headline metrics) or full (all policies and metrics), and analysis and metric rollup offer a Force full rebuild toggle that drops persisted state and recomputes history. SDK sync offers a Full resync toggle instead: it drops the synced tables and re-reads a short lookback rather than all history. Full rebuilds are slow; normal runs are incremental. Manual runs are useful for:

• Re-running after fixing a broken definition
• Pulling in late-arriving data after a backfill
• Verifying a freshly saved definition works against real data

Manual runs don’t disturb the regular cadence — the next scheduled run proceeds as usual.

​

Data Freshness

The Data Freshness page shows, per assignment and fact definition, how current the computed data is. Each definition carries a delivered-until watermark: data is considered delivered up to that timestamp, and the next analysis run resumes ingesting from there (with an overlap, so late data near the mark is still caught). A stalled mark doesn’t lose data — each run re-reads a widening window until the mark moves again, which costs compute rather than correctness. The Age column colors the gap — green under 15 minutes, amber up to two hours, red beyond. The Strategy column shows how the watermark advances:

• auto — successful analysis runs advance it. If runs fail, the watermark holds where it is; a mark that stops moving is your cue to check Workflow Runs for the failure.
• manual — the mark is set explicitly rather than advanced by runs. Manual marks show a pencil so you can adjust the timestamp yourself.

A new definition has no freshness mark until its first successful analysis run. If SDK event sync is enabled for your warehouse, a sources card at the top shows sync health — every definition reading from the synced tables can only be as fresh as the sync itself.

​

When numbers lag

If a metric looks stale on the Metrics page or a policy’s measurement progress has stopped advancing:

1. Check Data Freshness — is the relevant definition’s watermark moving?
2. If not, open Workflow Runs filtered to failed/partial and look at the failing step’s error and rendered SQL.
3. Common causes: warehouse credential rotated, table renamed in a migration, column changed type.

Pipeline failures can also notify you directly — see Notifications. For a broader symptom-by-symptom guide, see Troubleshooting.

​

Scheduling

Each workflow kind has a default cadence: Adaptive policies get the faster analysis lane by default because the optimizer acts on the results; A/B results only need to be as fresh as your reading of them. Override any cadence in Settings → Pipeline scheduling (Settings). Longer intervals cut warehouse cost; shorter intervals keep dashboards fresher. One guard applies: the assignment extract feeds analysis and dashboard rollups, so it can’t be scheduled less often than either of them. Scheduled runs only fire when Automatic pipeline runs is enabled on the warehouse connection (Settings → Warehouse). Manual triggers work either way.

​

Next steps