Your deploy log says nothing shipped. Something still changed.

A metric moves on a Tuesday afternoon. Someone asks the obvious question, an engineer opens the deploy log, and the last deploy was Friday. The honest answer comes back: nothing changed.

Except three things did. Someone edited a price in Stripe at 2:14pm. A feature flag went from 50% to 100% an hour earlier. Marketing republished the pricing page over lunch. None of that is in the deploy log, because none of it went anywhere near the repository.

“What changed?” describes three different tools

The phrase gets used for three genuinely different products. Confusing them is what leads teams to buy one, assume they are covered, and keep having the same Tuesday.

1. Deploy tracking

Deploy trackers answer “what code shipped, and did it break anything?” They watch commits, builds, releases and infrastructure config, then line those events up against error rates and latency. Datadog, New Relic, Sentry and Sleuth all live here. For code regressions they are excellent, and if you have an engineering team you almost certainly want one.

Their blind spot is definitional rather than accidental: if a change did not pass through the deploy pipeline, it does not exist.

2. Statistical attribution

Analytics tools answer “which segment moved?” — not “what changed?” Point them at a drop and they will slice the data they already own and report that APAC fell, or iOS fell, or first-time visitors fell. That is a real and useful capability, and it is not the same question.

Knowing the drop is concentrated in mobile checkout narrows where to look. It still does not tell you that someone changed the mobile checkout copy that morning. It describes the shape of the effect, not the cause.

3. Change attribution

Change attribution answers “which human changed which thing, when.” A price edited at 2:14pm. A flag pushed to everyone at 1:07pm. A page republished at 12:40pm. Not correlated, not inferred — recorded, across every tool where somebody can change what a customer experiences.

This is the layer most teams have no tool for at all. The underlying records usually exist — Stripe keeps its events, your CMS keeps revisions, your flag platform keeps an audit log — but each lives in its own tool, in its own format, behind its own login, readable mostly by whoever administers that tool. Nobody rolls them into one place.

Why the gap is architectural, not a missing integration

It is tempting to assume the deploy trackers will simply add a Stripe connector. The reason they have not is structural: their timelines hang each change off a monitored software entity — a service, a host, a container — so the change can be overlaid on that entity’s metrics.

A price edited in Stripe has no service. No host, no trace, no latency graph to sit on top of. New Relic makes this explicit: a change must attach to an entity to be recorded at all. So it is not that the Stripe integration is on the roadmap; there is nowhere in the data model to put it.

How big is your blind spot?

It scales with how many people can change what customers see without writing code. A quick way to size it: list everyone who could, this week, change something a customer would notice — without opening a pull request.

• Anyone who can edit a price, coupon, tax rule or trial length in the billing dashboard
• Anyone who can move a feature flag, including to a single customer
• Anyone who can publish a page, change copy, or swap an image in the CMS
• Anyone who can edit a record in the spreadsheet or Airtable base that production reads from
• Anyone who can change a storefront, a theme, or shipping and tax settings

At a ten-person company that list is usually most of the company. Every name on it can cause a Tuesday that the deploy log will describe as a quiet week.

Closing the gap

1. Inventory the non-code surfaces. Use the list above. Most teams find five to ten tools where a change goes live with no review and no record anyone reads.
2. Get those changes into one place, in time order. The value is in the adjacency: a price change at 2:14pm is unremarkable until you see the flag rollout at 1:07pm sitting directly above it.
3. Make it answerable by the person who gets asked. A timeline only an engineer can query has moved the bottleneck, not removed it. The founder or PM fielding the question needs to answer it without filing a request.

Where Rearview fits

Rearview is built for the third category. It connects to the tools where non-code changes happen — billing, storefronts, CMS, feature flags — alongside deploys, puts them on one searchable timeline, and lets anyone ask in plain English from Slack. Anything without a native connector can post to a simple change events API.

It is not a monitoring tool and does not try to be. Monitoring tells you something is wrong; this tells you what changed right before it went wrong. Most teams want both — see how it compares to Datadog Change Tracking.