## TL;DR
Start at the raw event table, not the dashboard. If raw events for the account stopped at the same minute a deploy, key rotation, or ingestion change landed, the customer did not churn overnight, the pipeline stopped recording them. Restore ingestion for that account segment, replay the buffered events, and only then re-score health.

```text
customer usage dropped to zero overnight: how to fix the missing usage data
```

## Use this when
- One account or segment dropped to exactly zero overnight
- Raw events and the aggregated dashboard disagree
- The drop lines up with a deploy or ingestion change

## Not for this skill when
- Usage is sliding over weeks, not to zero in a day
- Every account dropped together after a confirmed outage

## Steps
1. Pick three known-active users on the account and query raw events for the last 48 hours by account id. Verify: raw rows exist after the flatline time, or their absence is confirmed in the raw store, not just the rollup
2. Compare the last successful ingestion timestamp per source (web, mobile, server, API) for this account. Verify: the broken source and its exact stop time are named
3. Check deploys, SDK releases, and ingestion key or schema changes inside that stop window. Verify: one change is tied to the stop time or ruled out with timestamps
4. Restore that source, send a test event with the account id, and watch it land end to end. Verify: the test event appears in raw storage and in the hourly rollup
5. Backfill from the source buffer or warehouse staging, dedupe on event id, then recompute usage and health. Verify: the backfilled curve is continuous with no double-counted day

## Variant phrasings
### customer usage zero in dashboard but users still active
A related phrasing for the same underlying problem.
### usage events stopped ingesting for one account
A related phrasing for the same underlying problem.
### overnight flatline in product analytics
A related phrasing for the same underlying problem.

Compatibility: Compatibility: product analytics and warehouse pipelines (Segment-style ingestion, Snowflake or BigQuery rollups, dbt aggregates) in current versions.

## Why it happens
Dashboards read aggregates, and aggregates hide where the chain broke. A single account going to true zero is statistically rare; a filter, join, or ingestion key change that excludes that account is common. The aggregate cannot tell you which happened, the raw event store can.

## Edge cases / pitfalls
- Zero can be real during a customer holiday or freeze window. Confirm with login or API-key activity before declaring a pipeline break.
- A backfill without event-id dedupe inflates the recovery day and can flip the account to falsely healthy.
- If the account migrated to a new account id, usage may be recording correctly under the new id. Check identity mapping before replaying.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TC7ix6anPp9muqdziHaknw