Datavor v3.0: a Web UI to watch your pipelines, and alerts when they break

Datavor has always been driven by conversation. You tell your AI tool what to do — "sync orders to the warehouse," "start CDC on the customers table" — and it calls the right MCP tools. That model is fast and it's how we think Datavor should work.

But conversation has a blind spot: visibility. Between sessions, when you're not actively asking, what is Datavor actually doing? Which syncs ran overnight? Is that CDC stream keeping up? When a job failed at 2am, did anything tell you? v3.0 is about closing that gap — without compromising the conversational model.

A window, not a control panel

The headline feature of v3.0 is the Web UI — a local dashboard that runs at localhost:3000. Ask your AI to "open the Datavor dashboard," run datavor webui from your terminal, or just visit the URL if Datavor's already running.

The most important design decision: it's read-only. The dashboard has no destructive buttons, no "are you sure?" dialogs, no way to accidentally drop a sync or edit a job. To change anything, you still talk to your AI. The UI exists purely to show you what's happening — and because it reads from the same Context Engine your AI writes to, it can never drift out of sync with reality.

Six sections cover everything Datavor tracks:

• Dashboard — headline metrics, a 7-day sync activity chart, and pending suggestions at a glance
• Connections — every database, its engine type, table count, and last-connected time
• Context Graph — a visual map of connections, tables, and sync relationships with health-colored edges
• CDC Monitor — live stream status, refreshing every 5 seconds
• Scheduler — every job, its schedule, last result, and dependency graph
• Settings — appearance, alert webhooks, and Pro licence status

Most views refresh every 30 seconds; the CDC monitor refreshes every 5, because real-time replication deserves a real-time view.

Alerts, so you don't have to watch

A dashboard is great when you're looking at it. But the failures that hurt are the ones that happen when you're not. That's why v3.0 also ships External Alerting — push notifications for the events that matter, delivered to Slack or any webhook endpoint.

Six event types fire alerts:

• sync_failure — a sync job fails as a whole (after per-record fault tolerance has done its job)
• cdc_error — a running CDC stream hits a problem
• cdc_stopped — a CDC stream stops, cleanly or otherwise
• schema_change — a source schema change is detected
• suggestion_new — the Context Engine surfaces a new suggestion
• job_failure — any scheduled job fails, including query and transform jobs

Slack gets first-class treatment

Paste a Slack incoming-webhook URL and Datavor formats events as Slack Block Kit messages — structured and readable, with the event type, affected resource, and detail laid out as blocks instead of a wall of JSON.

Slack rate-limits incoming webhooks to roughly one message per second, and a burst of schema changes or sync failures could easily trip that and drop your alerts. So Datavor applies per-URL serial throttling: events to the same Slack URL are queued and delivered in series, never faster than Slack accepts them. Your alerts arrive — just paced.

You configure both from the Settings page in the Web UI. Toggle Enable alerting, add one or more webhook URLs, and saved webhooks fire immediately — no restart needed.

Why this matters

Datavor's whole pitch is that it runs locally and gets out of your way. The risk with "gets out of your way" is that it can also mean "leaves you in the dark." v3.0 resolves that tension: the conversational model stays exactly as it was, but now there's a window to look through when you want one, and a tap on the shoulder when something breaks.

You shouldn't have to ask to find out something's wrong.

Both features ship with every Datavor install, Free and Pro. The Web UI is documented on the Web UI page, and the full alerting spec — events, Block Kit formatting, throttling, the JSON envelope — lives in the docs.