PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A green dbt run shows that the work the run performed completed without a reported failure; it does not prove that every expected sales record arrived or that a model selected every historical row. To find out why three months are missing, preserve the affected run evidence, compare the same sales definition across each data layer, and inspect the incremental logic at the first point where dates or totals diverge. Without the production SQL, warehouse, adapter, and run artifacts, no single root cause can be established.
What a green dbt run does—and does not—tell you
dbt incremental models rely on model-defined logic to choose which source rows to process on later runs. As dbt Developer Hub explains in its incremental-model guidance, “On subsequent runs, dbt transforms only the rows in your source data that you tell it to filter for, inserting them into the target table which is the table that has already been built.” A successful run therefore does not establish that the chosen rows covered every date or included every late-arriving change.
Source freshness is a separate check. dbt documents that dbt build does not run source freshness checks. A build can be green even if a source has stopped updating, unless freshness is configured and checked separately. And a freshness check measures the configured age of data; it does not prove that the source contains all expected sales or that its business totals are correct.
Those distinctions explain how missing data can coexist with green runs, but they do not identify the cause of this incident. Treat an incremental-filter defect, a stale source, or a transformation issue as hypotheses to test—not findings.
#1 Best Overall
Preserve run evidence before changing the pipeline
Before rerunning models, backfilling, or replacing artifacts, retain what can show what happened in the affected production runs. Evidence may include run_results.json, freshness results when available, logs, compiled SQL, and relevant warehouse query history. dbt’s debugging guidance identifies compiled files, logs, and warehouse-side merge, update, or insert statements as useful parts of an investigation. The available artifacts and details can depend on the project’s dbt version.
This matters because a rerun can change the target state and overwrite evidence of the original behavior. Keep copies of the affected artifacts and record which runs and dates they represent before beginning recovery.
Find the first layer where sales disappear
Define the missing interval precisely
First decide what “sales” means in this pipeline: for example, which records count, how cancellations or returns are treated, and whether totals are based on order date, payment date, or another business event. Pin down the three-month interval using the business’s date rules and timezone. A date boundary based on UTC may not match a reporting day defined in a local timezone.
Compare the same measure through the pipeline
For each affected date, compare record counts, date coverage, and relevant sales totals in the raw source, staging models, intermediate models, and final mart. Use the same filters and sales definition at every layer. The first layer where the dates or totals diverge narrows the investigation: it tells you where to examine executed SQL and data handling rather than guessing from the final table alone.
Also check upstream load history. If the expected records are absent from the raw source, the issue may be delivery or source completeness; if they are present there but missing downstream, focus on the transformation path. This comparison locates the divergence—it does not, by itself, prove why it occurred.
Inspect incremental selection and warehouse behavior
At the first divergent model, inspect the compiled and executed SQL, including the incremental branch and its filter. Trace the watermark to the field and table that supply it, then compare that value with the target’s existing maximum timestamp and the dates of the missing records.
- Check whether the predicate selects only records newer than a target watermark. Late-arriving or backfilled rows can fall outside that selection even when they belong to an earlier missing date.
- Check whether records can be updated after their original arrival and whether the model’s logic revisits them.
- If the model uses a
unique_key, check what identifies a row and whether the warehouse’s merge behavior updates or inserts the rows as intended. A key helps identify rows for updates; it does not make an incomplete selection filter complete. - Compare dbt’s executed SQL with warehouse query history and inspect the actual merge, update, or insert statements. Adapter and warehouse behavior can differ.
These checks test common failure modes; none should be described as the cause unless the production evidence supports it. dbt’s incremental guidance also discusses schema-change options and flags time-sensitive warehouse compatibility considerations. Check the official documentation and the installed adapter version before applying version-specific advice.
Check source freshness separately from sales completeness
For every relevant source, determine whether freshness was configured and whether the check ran in the production workflow with the intended failure behavior. Review its results alongside source-load history. If no freshness check ran, a green build does not rule out an aging source.
Freshness is only one signal. A source can be recent yet incomplete, and a configured age threshold does not validate daily sales volume or business totals. Compare expected date coverage and totals with upstream records or another authoritative source when one is available.
Use snapshots carefully when past source states matter
dbt snapshots can record changes in mutable source data, but they preserve only the states they observe. Their history depends on when and how often they run, so they cannot reconstruct earlier states that were never captured. This makes snapshots potentially useful evidence when they were already part of the pipeline, not a retroactive repair for history that was not recorded.
Snapshot placement also matters: dbt Labs cautions that a snapshot taken in the middle of a DAG can expose downstream history to upstream modeling bugs. Assess the snapshot’s position and cadence before treating its records as a reliable account of source history.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesRepair the affected dates only after identifying the failure point
Once the divergence and the rows to restore are understood, choose a backfill or rebuild procedure that matches the model’s incremental strategy, adapter, warehouse, and recovery controls. Those details are not established here, so there is no safe universal command or warehouse operation to prescribe. Preserve the original evidence, define the exact repair interval, and verify the corrected dates and totals through the downstream models before relying on the mart again.
Prevent the same gap from passing unnoticed
Choose checks that correspond to the failure mode found, and make sure they run in the production workflow:
- Test expected date coverage so a missing period is visible even if individual model runs succeed.
- Where daily sales should be present, use a nonzero or thresholded volume check with rules that account for legitimate zero-sales days.
- Reconcile relevant daily totals against an authoritative upstream measure when one is available.
- Configure and run source freshness checks for sources whose age matters, with failure behavior that matches operational needs.
- Retain run artifacts and logs long enough to compare affected runs and spot changes in coverage or results.
No generic test suite guarantees that every business-data defect will be caught. Tests are most useful when they express a specific expectation about the data and are connected to the workflow that should act on a failure.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →
