Built into DBConvert Streams. No external monitoring stack to deploy.
Observability for data streams means knowing what each stream is doing right now, what it did before, and exactly which queries it ran against the source and target. Without it, a stuck migration or a slow CDC run becomes guesswork — checked by tailing logs, hitting databases manually, and reconstructing what happened from memory.
DBConvert Streams ships with built-in observability for every stream: the live monitor shows reader and writer activity, table progress, and current throughput; the SQL audit lists every query the engine ran with timing and context; and persistent run history keeps a record of each execution per configuration so failures can be compared and explained later.
Follow reader and writer activity as it happens, including stage, throughput, and table progress.
Live monitor view with stage, rate, and table-level progress in one panel.
Target Delivery becomes S3 upload only when object storage is the selected target.
Track executed SQL with timing and context across streaming and schema exploration workflows.
SQL logs with grouped view, filtering, and expanded query details.
Diagnose incidents faster with searchable logs and historical run records per configuration.
System log timeline with stage and transfer events.
Persistent run history for audit and comparison.
Log export support: JSON, CSV, and plain text from UI or API.
Performance
Measure current and cumulative rate, then isolate slow tables or target-side bottlenecks.
Short-term throughput in the current window
Current transfer speed at this moment
Cumulative throughput from start to now
Counters and stage updates are part of the stream lifecycle and run inline — they do not require a separate agent or external metrics backend. SQL audit and log capture run at the engine level, so there is nothing to install on the source or target.
Yes. Stream state, throughput, run history, and logs are accessible through the DBConvert Streams REST API in addition to the built-in UI, so they can be queried by external tools or scripts.
The stream enters an explicit FAILED state, the failure point is preserved in run history, the SQL audit shows which query caused or surrounded the failure, and the stream resumes from its last committed checkpoint when restarted — not from the beginning.
Monitor, audit, and diagnose every stream run from a single interface.
Your AI assistant can read the same status, errors, and logs — AI assistants via MCP.