Pipeline Anomaly Triage (QA)

Pipeline Anomaly Triage (QA)

1. 01

   Freeze downstream automation the moment an anomaly alert fires

   Pause scheduled syncs, outbound sends, and reporting refreshes that read from the affected table so a bad batch does not propagate into client-facing dashboards or CRM records.

2. 02

   Classify the anomaly by blast radius before opening a fix

   Tag it as single-record, single-pipeline, or cross-system. A duplicate row in one spreadsheet is a different incident than a master data sync writing conflicting values into three client systems.

3. 03

   Pull the last known-good snapshot and diff it against current state

   Record row counts, null rates, and distinct-value counts for the affected fields. The diff is the evidence you will attach to the client update, not a verbal summary.

4. 04

   Trace the break to its origin layer: source, transform, or destination

   Check whether the source system changed a field format, whether a transformation step dropped records, or whether the destination rejected writes. Observability tooling on the pipeline narrows this in minutes rather than hours.

5. 05

   Apply the narrowest corrective action that restores trust

   Backfill the missing window or re-run the failed transform rather than rebuilding the whole pipeline. Broad rebuilds during an incident introduce new variables while the client is already watching.

6. 06

   Reconcile the corrected data against the client's system of record

   Confirm totals match the client's own numbers before you declare resolution. A fix that satisfies your pipeline but disagrees with the client's finance or CRM export is not resolved.

7. 07

   Write a two-paragraph incident note and log the root cause

   State what broke, what window of data was affected, and what monitoring rule now catches the same failure earlier. File it in the account folder so the next retainer review has a documented reliability record.