CEDX Sync · Data & Analytics
Sync moves data from sources into the warehouse estate: 72 jobs, 48 connectors, per-job freshness SLAs — and a breach queue that names the worst offender instead of averaging it away.
The Lag & freshness screen leads with its worst row: returns-com→wh-core-26 at 92 minutes against a 45-minute SLA. Pipeline honesty is a breach queue, not an uptime badge.
Runs on demo data — the header reads “warehouse lag ~14m · demo seed” on the screen itself.
What it is
Every job carries mode, lag, SLA and rows per day: returns-com→wh-core-26 runs incremental at 92m against 45m and is marked degraded; the events archive appends 6.4M rows a day at 90m against a 180m SLA and stays healthy.
The connector list carries type, domain, table count, rows per day, lag and status: file drops, database CDC, SaaS extracts, APIs and webhooks. The events archive leads volume at 6.4M rows a day across 8 tables.
18 tables sit in open drift, and the alert feed names the CRM-to-warehouse job at 48 minutes against a 30-minute SLA with the reason attached — full-refresh mode on 64 tables cannot finish inside the 6-hour schedule.
Product tour
Not a mockup and not a concept deck. This is what opens at /app/sync.
01 — Overview
48.2M rows a day, 97.8% success, 14m p95 lag, 72 active jobs of 78 registered, 7 failed runs in 24 hours. Pipeline health reads 93 with the components — drift tables, failed runs, breach jobs, average lag — listed beside it.
02 — Lag & freshness
p95 lag at 86m across all jobs, 24 of 72 breaching SLA. The queue sorts worst-first with the SLA it broke and the rows it carries — 92 minutes against 45, at 1.4M rows a day, on top.
03 — Connectors
48 connectors across commerce, payments, support, inventory and marketing. The checkout extract shows failed at 39m lag; the Postgres orders CDC connector runs 42 tables at 6m lag, healthy.
Who runs it
Roles, not references. We have no named customers yet, so nobody in these photographs is quoted, credited or claimed as one.
Owns the breach queue: rallies the 7 failed runs, works the 24 SLA breaches worst-first, and watches the CRM job's 48-minute lag against its 30-minute SLA.
breach queue · 24 jobs
Maintains the 48 connectors — credentials, modes and schedules — and reads the drift list before the business does.
connectors · 11 unhealthy
The domain teams who consume the rows. They see lag and drift on the same screens engineering does, so “the data is stale” has a number attached.
open drift · 18 tablesThe shape of it
Every figure below is legible in the captures above. Nothing here is a projection of your estate — it is the state of the demo data.
How it runs
A source becomes a typed connector — files, CDC, extract, API or webhook — with tables and a schedule.
Jobs run in their mode — full refresh, incremental, append-only or CDC — carrying rows per day and lag with them.
Lag is compared to each job's SLA continuously; breaches sort into the queue worst-first.
Failed and partial runs rally from the overview; the alert says why — full-refresh mode on 64 tables cannot fit the 6-hour window.
One record
Sync is not an import wizard. Its jobs, lags and drift flags are the same record the warehouse's freshness SLAs and the metric layer's freshness figures are computed from.
Sync is how the warehouse's 320 tables stay inside their freshness SLAs — a lag breach here lands there as a stale table.
CEDX InsightMetrics computed on synced rows inherit this lag; the metric layer's 18.1h average freshness starts at these jobs.
CEDX EventsThe webhook and CDC sources on the connector list are the same event spine the rest of the estate publishes to.
CEDX TablesSynced rows surface to operators through Tables — drift flags here are visible where the data is worked.
Limits
Finding this out on the third call is worse for you than reading it here, and worse for us.
Start
Open it right now
Your sources, metered
Sync with the rest of it
Questions
Yes. Every screenshot is a capture of the running build, and you can open the same build at /app/sync. It runs on demo data, which the header states on screen.
It sorts into the breach queue with its lag, its SLA and its rows per day, worst first — and the worst job is named on the header card. The alert root-causes it: the CRM job's 48-minute lag traces to full-refresh mode on 64 tables not fitting the 6-hour schedule.
The connector screen shows the demo estate's types: S3 and GCS files, MySQL and Postgres CDC, SaaS extracts, APIs and webhooks. What we support for a given source of yours is a pilot conversation — this page does not claim a matrix.
Lag is time: how far behind its SLA a job is. Drift is divergence: rows that no longer match between source and destination. 18 tables sit in open drift, and the contacts table is flagged at 2.4% row drift in the alert feed.
No certification has been issued. What we can evidence about hosting, encryption, tenant isolation and production access is written up on the security page.
Live build, demo data, no card. The breach queue sorts itself worst-first, which is the only honest way to sort it.