You Just Found Bad Data in Production. Now What?

Pinal Dave argues that data quality incidents are a widespread operational blind spot. Teams plan for server failures but rarely for wrong data, which is uniquely dangerous because it looks correct — dashboards render, APIs return values, and bad decisions compound before anyone notices.

The article lays out a six-step response playbook: (1) triage by asking what exactly is wrong, how far it spread, and who is already acting on it; (2) contain the spread before attempting cleanup, using the metaphor of mopping while the tap is still running; (3) trace the full data lineage — from dashboard back to source feed — rather than patching the visible symptom; (4) fix, then re-run the original diagnostic and inspect downstream dependencies to verify; (5) notify anyone who trusted the bad number directly and personally, before they hear it elsewhere; (6) run a short, blameless review aimed at one concrete prevention, not an exhaustive report.

The closing emphasis is cultural: good teams do have data incidents. The ones worth trusting are those that handle them calmly, methodically, and ensure the same failure doesn't happen twice. Dave also promotes his Pluralsight course on responding to data quality incidents.