What Is Data Downtime, and What Does It Cost You?

Data downtime is any period when your data is wrong, missing, late, or otherwise untrustworthy, even if every pipeline reports success. It is the data equivalent of system downtime, but instead of a server being unreachable, a table is stale, a load is partial, a schema changed, or a column's values quietly went bad. The cost shows up as bad decisions, lost engineering hours, and eroded trust, and it is measured the same way you measure any reliability problem: by how often it happens and how long it lasts before someone fixes it.

What counts as data downtime

Data downtime is broader than an outage. The pipeline is often green the entire time. The data is what is broken. Common forms:

• Staleness. A table that should load hourly has not updated since midnight, so the dashboard shows yesterday's numbers as if they were live.
• Partial or missing data. A load that normally brings 200,000 rows brings 4,000 because an upstream filter broke, so every aggregate is understated.
• Schema breakage. An upstream team renames customers.email to email_address, silently nulling a downstream join.
• Bad values. A unit change makes orders.revenue inflate 100x, or a null rate on orders.customer_id jumps from 1 percent to 40 percent.
• Duplicate loads. A retried job double-loads a partition, inflating counts.

In every case the warehouse is up, the dbt run exited zero, and the orchestrator is green. The data is still wrong. That gap is exactly what data downtime names.

How data downtime happens

Data downtime almost always originates upstream and propagates downstream before anyone notices. A typical sequence:

1. An upstream SaaS source changes an API field or stops sending data.
2. The raw load to raw.stripe.charges comes in late or short.
3. The staging model stg_stripe_charges runs anyway on whatever it got.
4. fct_orders aggregates the bad staging data.
5. The revenue dashboard shows a number that is wrong but plausible.
6. Hours later, a finance lead spots it and pings the data team.

The propagation step is what makes data downtime expensive. A single upstream miss fans out across the lineage graph into every downstream model and dashboard. Without lineage, the team that finally gets the ping has to manually trace the problem back through the chain. With lineage, the blast radius is visible the moment the upstream issue is detected.

Measuring data downtime

You cannot improve what you do not measure, and data downtime borrows its metrics directly from incident management. The two that matter most are time to detection and time to resolution.

Time to detection (TTD) is how long the data is wrong before anyone or anything notices. If raw.stripe.charges stops loading at midnight and the finance lead spots the bad dashboard at 10am, your TTD is ten hours. TTD is the metric observability tooling exists to crush, because the longer data is wrong undetected, the more decisions get made on it.

Time to resolution (TTR) is how long from detection to fix. This is where lineage pays off: a fast trace-to-source and a clear blast radius cut the diagnosis time that dominates TTR. Knowing instantly that the missing division lives in stg_stripe_charges turns a multi-hour hunt into a one-line fix.

The headline number combines these across incidents:

data downtime = number of incidents x average duration

where duration is roughly TTD plus TTR. Cut either the count of incidents or their duration and total downtime falls.

What data downtime costs

The cost is real even though it rarely shows up on a single line item. It accumulates in several ways:

• Bad decisions. When a revenue or pipeline number is wrong for hours, people act on it: forecasts, spend, headcount, and customer-facing reports all get built on bad inputs.
• Engineering time. Every incident pulls engineers off roadmap work to firefight. Diagnosis without lineage can eat an afternoon per incident.
• Eroded trust. The most expensive cost is cultural. Once stakeholders catch the dashboard being wrong a few times, they stop trusting all of it and revert to spreadsheets, which defeats the purpose of the warehouse.

Trust is slow to build and fast to lose, and a few visible data-downtime incidents can undo months of work convincing a team to rely on the warehouse.

Catching it before a person does

The goal of data observability is to make a monitor detect the problem before a stakeholder does, which collapses TTD from hours to minutes. That means watching the data itself, not just the pipeline:

• Freshness checks catch the stale load. A late raw.stripe.charges pages the team at 12:15am, not the finance lead at 10am. See freshness monitoring.
• Volume checks catch the partial and duplicate loads when a row count falls outside its normal range.
• Schema checks catch the rename before the join silently nulls, with a schema change alert that names the affected downstream assets.
• Distribution checks catch the bad values, like the 100x revenue inflation or the null-rate spike, through anomaly detection on column statistics.
• Lineage turns every one of those alerts into a blast radius and a trace-to-source, which is what slashes TTR.

All of this runs by reading warehouse metadata, system tables, and query history. A proper monitor connects read-only by design and never moves or mutates your data; detecting downtime should never risk causing it.

Reducing your own data downtime

If you want to measure and shrink your team's data downtime, the starting point is continuous checks across the five pillars plus lineage so that the first wrong byte triggers an alert with its full downstream impact attached. If you are picking a monitor to do that, the data observability tools comparison covers what each platform actually detects. You can see how Datatrail detects freshness, volume, schema, and distribution issues against a read-only connection to Snowflake, BigQuery, Redshift, or Postgres, and ties each one back to the source and forward to the dashboards at risk.