Comparison
Data downtimevsPipeline run history
Data downtime
the numbers were wrong from Tuesday 02:00 until someone noticed on Thursday afternoon, and that gap is the thing worth measuring.
The period during which data was missing, wrong or stale, measured from when it broke to when it was fixed. Naming it as downtime is the useful move: it makes detection time visible as a separate number from repair time, and detection time in data teams is routinely measured in days. Almost every investment in quality checks is an argument about reducing the first number.
Full entry →Pipeline run history
you need to know whether last Tuesday's run of this model succeeded, and how long it took the last thirty times.
The retained record of every execution, its parameters, its duration and its outcome. It is the difference between an orchestrator and cron, because most operational questions — is this slower than usual, when did this start failing, was this period ever run — are queries against it. It is also what makes durations a leading indicator: a job that has crept from four minutes to eleven is telling you something before it starts timing out.
Full entry →