## TL;DR
An event missing from Amplitude is not always an instrumentation bug. When an event is dropped for a plan limit, Amplitude accepted the traffic pattern upstream and then discarded this event type under your event volume or governance controls, so the churn report loses exactly the cancellations it exists to count. Check the ingestion and governance views for dropped or blocked status on subscription_cancelled, restore that event, and backfill cancellations from the billing system of record.

```text
Amplitude event dropped due to plan limit: subscription_cancelled missing from churn report
```

## Use this when
- subscription_cancelled appears in billing or Stripe but never in Amplitude charts
- Amplitude governance or ingestion pages show dropped, blocked, or silenced events
- Other events from the same app and release still arrive normally

## Not for this skill when
- The application code never fires the event, which you can prove in a debug view with a test cancellation
- Every event type stopped at once, pointing at a broken API key or SDK release instead

## Steps
1. Reproduce one test cancellation in a staging or test project and watch the Amplitude user lookup and ingestion debugger in real time. Note whether the event is accepted, dropped, or never seen, because that single observation splits instrumentation faults from plan and governance faults. Verify: the test event outcome is recorded as accepted, dropped with a reason, or absent entirely
2. Open Amplitude Data, the governance and ingestion views for the production project, and find subscription_cancelled by exact name including case and spacing. Look for blocked, hidden, or dropped status and for a sudden drop count starting on a specific date, which often lines up with a traffic spike from a bot, a load test, or a backfill that consumed the event allowance. Verify: the event status and the date dropping started are both identified
3. Check the plan event volume position for the project and which event types consumed the growth. High-volume low-value events such as page pings or heartbeat events commonly crowd out rare, high-value lifecycle events. Decide with the data owner which noisy events to drop, sample, or move so lifecycle events are protected first. Verify: a named set of noisy events is cut or sampled and subscription_cancelled is explicitly protected
4. Remove the block or drop rule for subscription_cancelled and, where your plan allows, mark key lifecycle events so they are never the ones sacrificed. Send another test cancellation and follow it from the debugger into a saved chart to prove the whole path, not only ingestion. Verify: the test cancellation is visible in a chart within the normal ingestion delay
5. Backfill the gap from the billing system, because dropped Amplitude events are not replayable from Amplitude itself. Load the true cancellation records from Stripe, Chargebee, or your subscription table into the warehouse churn report with their original timestamps and mark the Amplitude series as incomplete for that window. Verify: the churn report shows the real cancellations for the gap window sourced from billing, with the gap annotated
6. Add a weekly reconciliation that compares cancellation counts in billing against cancellation events in Amplitude and alerts when they diverge beyond a small tolerance. Rare lifecycle events fail silently, so only a cross-system count check catches the next drop early. Verify: the reconciliation check exists, runs on a schedule, and fires on a deliberately introduced test mismatch

## Why it happens
Amplitude projects on volume-based plans protect the platform and the bill by dropping or blocking events when limits or governance rules bite. Lifecycle events are rare, so nobody notices their absence in top-line volume graphs, yet churn reporting depends on that one event type completely. The drop is therefore silent in every volume view and total in the one report that matters.

Compatibility: Amplitude HTTP API ingestion, Amplitude Data governance, and current Amplitude plans with event volume limits, plus Stripe or Chargebee as the billing source of truth.

## Variants and edge cases
### Amplitude subscription_cancelled event missing from report
['The report-level phrasing. Start from the billing count, not the chart, so you know how many cancellations the report should show before you debug why it shows fewer.']

### event dropped plan limit Amplitude how to restore
['The restore phrasing. Restoring means removing the drop or block and protecting the event, not merely raising volume, because the same noisy event mix will consume any new headroom.']

### Amplitude govern blocked event churn signal lost
['The governance variant, where a teammate blocked the event believing it was unused. Check change history and saved chart dependencies before unblocking, then document the event as load-bearing for churn.']

Edge cases to work through before you close the incident:
- Event names are unforgiving. A trailing space or a renamed subscription_canceled spelling variant can look like a dropped event while the real event flows under another name, so search variants before changing plan settings.
- Unblocking restores future events only. Anyone quoting churn for the gap window must use the billing backfill or the number stays wrong.
- If the volume spike came from a retry storm in your own SDK or server integration, fix that emitter or the limit will bite again next cycle.

## Provenance

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