customer usage dropped to zero overnight: how to fix the missing

Not specified by the original author.

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.

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

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

Thread query: customer usage dropped to zero overnight: how to fix the missing usage data

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.

Not specified by the original author.

TL;DR

The ordered checklist is eventtype mismatch (the #1 cause: eventtype does not match any billable metric's eventtypefilter, events silently ignored), wrong customerid or missing ingest alias, events older than 34 days (silently dropped), contract startingat in the future, and genuinely inactive customer.

Fix

1. The ordered checklist is eventtype mismatch (the #1 cause: eventtype does not match any billable metric's eventtypefilter, events silently ignored), wrong customerid or missing ingest alias, events older than 34 days (silently dropped), contract startingat in the future, and genuinely inactive customer. Expected: you can confirm this matches your situation.

When to use

• You are setting up or using this Metronome feature.
• The symptom matches: zero-usage contract - diagnostic order for events not billing.

When NOT to use

• Unrelated Metronome issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against Metronome. Source: https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md.

Variant phrasings

zero-usage contract - diagnostic order for events not billing

Why it happens

A customer's invoice shows zero usage even though events are being sent. Metronome silently drops bad events, so check in likelihood order.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md

Source: A customer's invoice shows zero usage even though events are being sent. Metronome silently drops bad events, so check in likelihood order.

Verified resolution: [metronome-industries/ai diagnostics]: the ordered checklist is eventtype mismatch (the #1 cause: eventtype does not match any billable metric's eventtypefilter, events silently ignored), wrong customerid or missing ingest alias, events older than 34 days (silently dropped), contract startingat in the future, and genuinely inactive customer. Verify with GET billable-metrics to compare eventtypefilter, searchEvents for the transaction prefix, and the customer's ingest_aliases. Watch string numbers in properties (tokens sent as a string breaks SUM aggregation) and case mismatches in pricing group keys, for example gpt-4 vs GPT-4, which bill to nothing on the invoice.

Source URL: https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md

Not specified by the original author.

TL;DR

Logins continuing while feature adoption reads zero means people arrive and the feature events never register. Check the flag state for the account, the exact event name the current build emits, and the adoption rollup filter. One of the three almost always changed while the others stayed put.

account usage flatlined: feature adoption dropped to zero troubleshooting

Use this when

• Login and session events are normal but feature events are zero
• Adoption dropped for one feature, not the whole product
• A release or flag change shipped near the flatline

Not for this skill when

• The feature was removed or paywalled for this plan
• All event types stopped, which points at ingestion instead

Steps

1. Pull raw events for the account and count by event name for 14 days. Verify: the missing events are named and the surviving events prove ingestion works
2. Check the feature flag and entitlement state for this account and plan tier. Verify: the account is confirmed eligible, or the flag change that cut it off is found
3. Compare the event name and properties in the current build against the rollup definition. Verify: any rename, namespacing, or property change is pinpointed
4. Patch the rollup or instrumentation, fire the feature once as a test user, and trace that event. Verify: the test event reaches the adoption table with the right account id
5. Recompute adoption for the gap window and annotate the flatline as an instrumentation break. Verify: the corrected adoption series no longer shows a false zero

Variant phrasings

feature adoption zero but logins normal

A related phrasing for the same underlying problem.

feature events missing from rollup

A related phrasing for the same underlying problem.

adoption metric flatlined after release

A related phrasing for the same underlying problem.

Compatibility: Compatibility: feature-flag systems and event analytics (LaunchDarkly-style flags, Mixpanel or Amplitude adoption reports, warehouse rollups), current versions.

Why it happens

Adoption is a derived metric with three moving parts: eligibility, instrumentation, and aggregation. A flatline in only one feature while sessions stay healthy rules out churn and rules in one of those three parts. Testing them in that order finds it fastest.

Edge cases / pitfalls

• A zero can be a sampling artifact in client-side analytics if the feature moved behind a consent or ad-block-heavy surface. Cross-check server logs.
• Renamed events sometimes keep flowing under the new name, so search by property values, not only by event name.
• Do not backfill adoption from session data. Sessions prove presence, not feature use.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstp5-ub-H7934Gep_688aVQ

Resolved from the public thread: https://vectle.com/posts/pstp5-ub-H7934Gep_688aVQ

Thread query: account usage flatlined: feature adoption dropped to zero troubleshooting

TL;DR: Logins continuing while feature adoption reads zero means people arrive and the feature events never register. Check the flag state for the account, the exact event name the current build emits, and the adoption rollup filter. One of the three almost always changed while the others stayed put.