Production reference
Workflow names, schedules and investigation records. The learning chapters explain how to interpret them.
Workflow details checked against dbt-analytics commit 18534e6 on 4 September 2026. The repository workflow files remain the source for later changes.
Read From merge to production for the delivery sequence and Observing production for a worked investigation.
Workflows
| Workflow | When it runs | What it does |
|---|---|---|
dbt-compile.yml | Every PR commit and the merge queue | Compiles against DEV metadata on a PR and PROD metadata before merge |
dbt-pr-validation.yml | The merge queue, or manual dispatch | Builds the exact merge candidate's state:modified nodes in the DEV__ databases |
dbt-deploy.yml | A relevant change is pushed to main | Builds changed nodes and their descendants in production |
dbt-scheduled.yml | Daily, weekly, monthly and intraday schedules | Refreshes production models, snapshots and the intraday SDL lineage |
Production jobs share the dbt-prod concurrency queue. Merge-queue validation has a separate serial queue because candidates write to shared DEV relations.
Scheduled selections
Times are UTC. The corresponding UK local time is one hour later during British Summer Time.
| Run | Time | Selection |
|---|---|---|
| Daily | 04:00, Sunday and Tuesday to Saturday | build --select +tag:daily source:olids+ resource_type:snapshot+ tag:indicator_definitions+ |
| Weekly | 04:00 Monday, skipped on the first of the month | build --select +staging+ tag:indicator_definitions+ |
| Monthly | 04:00 on the first | build --select +staging+ tag:indicator_definitions+ --full-refresh |
| SDL intraday | 07:00 and 12:00 daily | SDL refresh, then build --select source:sdl_wnl+ |
Snapshots are included in the daily build and ordered before their consumers. A snapshots-only run is available by manual dispatch. The first-of-month run replaces the weekly run when they coincide; the daily cron is separately defined.
Validation and deployment state
Validation builds state:modified nodes using the development target. With a deployed manifest, --defer --state state --favor-state resolves unselected parents to their recorded production relations. Without a manifest, validation falls back to directly changed nodes.
Deployment selects state:modified+. Manual dispatch or an absent state manifest triggers a full production build. A manifest is the structured record of project resources and configuration used for this comparison.
Once compilation succeeds and the build step runs, the deployment can publish a new baseline even if execution fails. A compilation failure, or a failure before building, preserves the previous baseline and stores available attempt artefacts. This behaviour is defined in the artefact publishing action. Scheduled runs do not advance deployment state.
The deployment workflow recognises [skip deploy] and [skip-deploy] markers. These are exceptional controls: skipped deployment can leave main ahead of the warehouse. The next state comparison still depends on the recorded deployment baseline.
Observability records
The Streamlit observability app reads from DATA_LAKE__NCL.DBT_OBSERVABILITY. Its implementation is in the observability repository.
| Elementary record | What it lets the app answer |
|---|---|
dbt_invocations | Which command, target, warehouse and selection ran, and when? |
dbt_run_results | Which models succeeded, failed or were skipped, and how long did they take? |
elementary_test_results | Which assertions passed, warned or failed, and is the problem recurring? |
dbt_models and dbt_tests | Which project resource, path, SQL and relationship does a result describe? |
ROW_COUNT_LOG | How have materialised table row counts changed over time? |
App pages
| Page | Use it to understand |
|---|---|
| Home | Current project health, the latest build and recent invocations |
| Alerts | Active and historical model or test failures, failure streaks and resolution time |
| Models | Models by project path, slow models and individual run histories |
| Tests | Test history, flaky tests and models for which no tests are recorded |
| Runs | Invocation selection, results, duration, skipped nodes and execution timeline |
| Growth | Unexpected growth or shrinkage in materialised table row counts |
| Performance | Total and average execution time, including the models consuming most build time |