Monitoring & runs

Live throughput, run history and data freshness.

BARRY gives you both a live view of data moving right now and a durable history of everything that has run — all on a single Monitor page with tabs. It is the one front door for "what is BARRY doing?".

Live metrics, in brief

While a transport runs, the client emits a metric roughly once a second on a lightweight control channel (separate from the data stream). Each message carries cumulative counts (rows and bytes processed) plus an instantaneous rate and any error count. The server keeps the latest state per run in memory and pushes it to the browser about once a second, so the numbers update smoothly and live; in parallel it writes the metrics to its database for history. The two paths are decoupled: a slow database degrades the history charts but never the live tiles.

The Monitor tabs

• Live — aggregate tiles across all running transports (active runs, throughput, rows/bytes in the rolling 24 h, failures) plus the in-flight run grid. Each in-flight row has a menu to view details, jump to its transport, or cancel the run. When nothing is running the tiles show zeros / last-known totals — never blank.
• Errors — a failure heatmap and the top error causes over a time window.
• Runs — the historical run list across transports (start, wait, duration, rows, bytes, status, error), with filtering and paging. Open a run for its detailed timings, throughput, per-run steps, and a link to its logs.
• Trigger — the upcoming scheduled fires within a chosen time window (a recurring trigger appears once per fire), so you can see what is due next.
• Transports — the per-transport drill-down: pick a transport for its freshness gauge, volume trend against its ±3σ band, run history and referenced objects. Every "Monitor" link elsewhere lands here with the transport preselected.
• Sources — a source-centric view of activity.
• Trends — throughput and wait / time-to-first-batch percentile trends bucketed over a window, and a per-connector comparison.

The active tab is reflected in the ?tab= URL, so a view is deep-linkable.

Freshness

Each transport with an interval schedule has a freshness signal — fresh / due / stale / none — comparing its last successful run to its cadence. It surfaces on the Transports tab and drives the at-a-glance health of the estate.

Run-log bundles

If run-log storage is configured (see Runtime Settings & Administration), each run captures a downloadable debug bundle — the server log, the client log, and a snapshot of the run record. From a run's detail, use Download bundle to retrieve it when diagnosing a failure. If run-log storage is left unconfigured, runs still complete normally but the bundle download is disabled.

Retention

Run records and their metrics are kept for a configurable retention window (30 days by default) before the runtime trims them. Live metrics are observability data and are kept on a shorter window than the rolled-up history. See Runtime Settings & Administration.

Monitoring from your phone

Away from your desk, the Mobile app gives you the short version of this page — what is running, what has failed, and which clients are online — plus push notifications when a run fails.