CLI icon
If icon
SlackIncomingWebhook icon
Log icon
Schedule icon

dlt Dataset Freshness Monitor

Catch dlt pipelines that stopped without failing. Kestra queries the _dlt_loads audit table, computes last-load age per dataset, and alerts Slack on staleness.

Categories
BusinessData

The most dangerous pipeline failure is the one that does not fail: a disabled schedule, a revoked credential on a machine nobody watches, an upstream that quietly stopped producing. This blueprint monitors the one artifact every dlt pipeline maintains for free, the _dlt_loads audit table, and computes how long ago each dataset last completed a load. Any dataset older than the threshold triggers a Slack alert naming it and its age; a healthy warehouse produces a quiet log line.

How it works

  1. check_freshness (io.kestra.plugin.dlt.CLI) ships a small Python script through inputFiles and runs it with commands. The script walks every schema in the warehouse, finds those containing a _dlt_loads table, and reads max(inserted_at) for completed loads (status = 0).
  2. Ages are computed in hours and emitted through Kestra's output protocol as both a full report and the stale subset.
  3. route_result (io.kestra.plugin.core.flow.If) branches on stale_count: breaches page Slack with dataset names and ages; a clean sweep logs the report for the execution history.
  4. The errors block alerts when the monitor itself cannot run, because an unmonitored warehouse feels identical to a healthy one until it is not.
  5. A disabled-by-default morning Schedule runs after the nightly loads should have landed.

What you get

  • Detection of silently stopped pipelines, the failure mode that never triggers an error alert on its own.
  • Zero instrumentation cost: dlt already writes the audit table on every load.
  • One monitor for every dlt dataset in the warehouse, present and future, since schemas are discovered at runtime.
  • A threshold as a flow input, so ad hoc runs can probe with stricter windows.

Who it's for

  • Data platform teams operating many dlt pipelines owned by different people.
  • On-call engineers who want one morning signal covering the whole warehouse.
  • Anyone who has been asked why a dashboard shows last Tuesday's data.

Why orchestrate this with Kestra

Freshness monitoring needs a scheduler, a place to run warehouse queries, branching logic, alert routing, and its own failure handling, exactly the primitives a workflow engine provides. Kestra runs the check on cadence, keeps every report in the execution history as a freshness time series, and guarantees that a monitor outage itself raises an alert instead of silence.

Prerequisites

  • A warehouse loaded by dlt pipelines (the script targets DuckDB; the SQL adapts to Postgres, BigQuery, or Snowflake with minor changes).
  • Read access to the warehouse from Kestra workers, with the path or credentials passed via task env.
  • A Slack incoming webhook.

Secrets

  • SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

  1. Add the SLACK_WEBHOOK_URL secret and set WAREHOUSE_DB_PATH in the task env to your warehouse location.
  2. Execute manually; confirm the log line lists every dlt dataset with its age.
  3. Set max_age_hours to fit your load cadence and enable the morning_check trigger.

How to extend

  • Adapt the connection block to Postgres or Snowflake; _dlt_loads has the same shape in every dlt destination.
  • Add per-dataset thresholds by mapping dataset names to expected cadences inside the script.
  • Escalate to PagerDuty when the same dataset is stale two mornings in a row, using Kestra KV to remember yesterday's result.
  • Emit the ages as metrics to Prometheus instead of Slack for dashboarding.

Links

Orchestrate with Kestra
Orchestrate Slack with Kestra
Share this Blueprint
See How

New to Kestra?

Use blueprints to kickstart your first workflows.