dbt models behind dashboards on fragile schedules

We follow each job's dbt selection to the models it builds, then downstream to dbt exposures, Looker explores and Tableau views. The rule flags a job that feeds any of those and has no retries or no failure alert.

A job with no alert that fails overnight leaves those dashboards showing yesterday's numbers as today's, and nobody is told. With no retries, one transient failure stops them until somebody reruns the job by hand.

Make the jobs behind dashboards retry and alert. Set retries and retry_delay on the job, and wire on_failure_callback to wherever the team is paged. Start with the jobs whose models feed the most dashboards.

Before:

DbtTaskGroup(
    group_id="marts",
    render_config=RenderConfig(select=["path:models/marts"]),
)

After:

DbtTaskGroup(
    group_id="marts",
    render_config=RenderConfig(select=["path:models/marts"]),
    default_args={
        "retries": 3,
        "on_failure_callback": notify_on_call_rota,
    },
)

Alerting configured centrally covers the job without appearing in its file. A job that builds only non-idempotent loads may be right to skip retries. Tell us which applies, and the finding comes out of your report.

The job files you name to us, manifest.json, and exposures, a LookML project or a Tableau workbook. A selection built at runtime, state: selectors or a dbt Cloud job cannot be traced, so we report could not tell, never unscheduled.