Product details
The mixed-kind list and the live job inside any one of them
Two mockups sit above. The first is the Runs list — one row per job, regardless of kind, with chip filters across the top and a live progress bar on every active row. The second is the detail view that opens when you click a row — the live CDC stream in the screenshot, with KPIs, engine state, cumulative deltas, per-table activity, and a tailable event log. The cards below walk through each one.
The mixed-kind list
The first mockup is one row per job, regardless of kind. Each row leads with the run title (CDC · plan or Snapshot · plan) and a copy-able run hash, then a KIND cell with an icon (broadcast for CDC, play-circle for Snapshot), a mono CONTEXT cell (the replication-plan ID for CDC runs, or a source-conn → target-conn pair for Snapshots), a status pill (amber RUNNING with a pulsing dot, green COMPLETED, gray STOPPED), a PROGRESS cell with a percent + row counter + a colored bar, and an ELAPSED cell on the right.
Filter chips at the top
Two rows of filter chips sit above the table. The KIND row narrows by job type (ALL / SNAPSHOT / CDC / REPAIR). The STATUS row narrows by lifecycle (ALL / RUNNING / QUEUED / COMPLETED / COMPLETED_WITH_ERRORS / STOPPED / FAILED). The active chip in each row glows amber. Both rows are sticky-feeling — they belong to the table — and the two header pills on the right of the page title roll up the result count: '1 ACTIVE' (amber with a pulsing dot) and '8 TOTAL' (gray).
The detail view that opens on click
Clicking a row drops you into the live run view (the second mockup). The page header repeats the run title with its broadcast icon, the amber RUNNING pill with its pulsing dot, the run hash chip, and a danger-styled 'Pause / Stop' button on the right — same screen as the metrics, no buried menu. The page below is divided into a main column with KPIs + engine + per-table activity + event tail, and a right rail with run metadata + connection context + a 'Live updating' panel.
The four KPI tiles
Rows replicated is the cumulative counter — 1,297,049 in the screenshot, all rows that have crossed since the stream started. Throughput is the average over the recent four cycles, with a green dot when it's healthy. Cycle # is the worker loop counter. Last activity is how long ago the worker emitted a heartbeat — 8s in the screenshot, well under any concerning lag. Together they answer 'is this stream actually moving?' in one glance.
The Engine card — binlog state in plain text
The Engine section names the engine type (binlog), the exact source position string (binlog:mysql-bin.000051:296660344;cdc:1781876523), the row count from the most recent cycle, and the cumulative inserts / updates / deletes broken into green / amber / red counts (+122 / ~1,296,927 / -14 in the screenshot). The source-position string is the part that lets a CDC engineer paste into a ticket and have someone debug whether the worker is stuck behind a long transaction or just keeping up with a busy source.
The event tail (and the LIVE TAIL pill)
Underneath is the live event stream — every CDC cycle, every checkpoint write, every table-cycle-applied event, with a timestamp, an info-marker icon, the event code (cdc_complet…, cdc_heartbe…, checkpoint_…), the human-readable message, the affected table (when the event names one), and a payload-expand caret. Filter chips on top narrow by severity (INFO / WARN / ERROR) and by table (all tables / users / quote_lines / quotes / global_search_history / audit_logs). LIVE TAIL on the right of the toolbar is the amber pulsing pill that says 'this list is updating; you don't need to refresh.'
The right rail — context the operator wants without scrolling
Run details names the started time, the completion state (in progress for active runs), the elapsed time updating in place, the plan, and the kind. Connection context names the saved Connection and its source + target with copy-able hashes — the same chips that appear on Connections and Reconcile, on purpose, so the IDs paste into tickets the same way across pages. Live updating is the small panel at the bottom that quietly reminds the operator the page is auto-refreshing every three seconds, so a missing event means there was no event.
One list, every job kind
Snapshots, CDC streams, repair jobs — they all land in the same ledger with the same columns. Filter chips at the top narrow by kind (SNAPSHOT / CDC / REPAIR) and by status (RUNNING / QUEUED / COMPLETED / COMPLETED_WITH_ERRORS / STOPPED / FAILED). Active runs get an amber gradient progress bar; finished ones get a green solid one.
A live view inside any row
Click a row and the detail view opens with four KPI tiles (rows replicated, throughput, cycle #, last activity), the engine card showing the source position string and cumulative inserts/updates/deletes, a per-table activity panel, and a live event tail with INFO / WARN / ERROR filters and per-table chips. The Live updating pill at the bottom right is a reminder that the page is refreshing every three seconds — no manual reload.
Pause / Stop within reach
The danger-styled Pause / Stop button sits in the run header — same screen as the KPIs, no buried menus, no confirm-then-confirm dance. When a CDC worker needs to be parked for a deploy, a sync run needs to be aborted because the source was wrong, or a repair needs to come to a clean halt, the control is one click from where the operator was already looking.
