Track Stripe pricing changes — and see what else changed that day

Billing is the highest-stakes surface most teams let people change without a deploy. A price, a coupon, a trial length, a tax setting or a webhook endpoint can be edited in a dashboard in about fifteen seconds, and it takes effect immediately, for real money.

When revenue moves a week later, the change is technically recorded — but recorded in a way that makes it very hard to connect to anything else that happened that day.

What Stripe already gives you

Stripe keeps a thorough record of what happened inside Stripe. Events, logs and audit history are all there, and for reconstructing the state of a single object they are the authoritative source. If you need to know exactly what a subscription looked like on a given date, that is where you go.

Two things it is not built to do:

• Read as a timeline. The record is organised per object and shaped for developers and finance. “Show me everything anyone changed in the last week, in order, in plain English” is not the question it is designed to answer.
• Know about anything outside Stripe. It cannot tell you the price edit landed the same afternoon as a checkout copy change and a feature flag rollout — and that adjacency is usually the actual answer.

What you actually want to see

The useful artifact is boring: one list, in time order, of every production-affecting change across every tool, with billing changes in it. Something like —

• 2:14pm — Stripe: Pro monthly price changed $49 → $59
• 1:07pm — LaunchDarkly: new-checkout flag 50% → 100%
• 12:40pm — Webflow: pricing page republished

Nothing there is clever. The value is entirely in the adjacency: three isolated, defensible changes that together explain a conversion drop nobody could account for, sitting in one place instead of three dashboards.

How to get billing changes onto that timeline

1. Point Stripe’s webhooks somewhere that keeps them

Stripe can notify an endpoint whenever objects change. The work is not receiving those events — it is verifying the signature, discarding duplicates, filtering to the events that actually matter, and turning price.updated into a sentence a non-engineer can read. Rearview ships a signature-verified, idempotent Stripe connector scoped to configuration changes, so routine charge traffic does not drown the signal.

2. Decide which billing events are production-critical

Not every Stripe event deserves attention; a successful charge is not news. Price, coupon, tax and plan changes usually are. Rearview lets you mark those as critical, which posts a real-time Slack alert the moment one ships — so a price change is something you hear about immediately, rather than reconstruct later.

3. Put the rest of the stack beside it

Billing alone is a better audit log. Billing next to deploys, flags, CMS publishes and storefront edits is an explanation. This is the same argument as change tracking vs deploy tracking, applied to the one surface where the changes cost money directly.

4. Cover the tools with no connector

Internal admin panels are usually where the rest of the pricing logic lives — the discount override, the grandfathered plan, the manual credit. Anything that can send an HTTP request can post to the Change Events API: a title, a timestamp, who did it, and an optional link. That is what keeps a homegrown billing screen from becoming the new blind spot.

Doing it without Rearview

This is buildable in-house, and it is worth being honest about the size of it. A Stripe webhook endpoint that verifies signatures and writes to a table is an afternoon. What takes longer is everything after: idempotency and replays, one normalisation layer per tool so events are comparable, a readable UI, retention, and the ongoing maintenance as each provider changes its payloads.

Plenty of teams do build it, and for a single source that is often the right call. It stops being a weekend project at about the third connector.