Analytics is not retroactive

You can fix the code tomorrow. You cannot recover the data from today. That is the part of broken analytics nobody plans for. A bug in a feature, you patch and redeploy. A metric you never recorded is gone for good, because you cannot backfill an event that did not fire.

Sentry catches runtime errors. Skene catches broken telemetry.

Key takeaways

• Analytics is not retroactive. You can fix the code tomorrow, but the data from today is already gone.
• Coding agents rewrite the code that records your events as a side effect of every feature, and nobody audits them.
• Skene runs on every pull request and catches the break while the data is still recoverable.
• Your Supabase schema is the contract. Skene checks that each event still matches the table it lands in.
• The agent that writes the tracking should not be the only thing checking it. The gate sits outside the tool that made the change.

The break you do not see

Product, growth, and pricing decisions run on event data. Funnels, retention, attribution. Those charts come from rows your app writes into Supabase, one insert per event, sitting in your code.

When one of those writes breaks, nothing turns red. The table does not error, it just stops filling. The dashboard keeps drawing, from data that is quietly missing. Nobody notices until a number looks wrong three sprints later, and by then the gap in the history is permanent.

Coding agents change instrumentation as a side effect

This used to be rare. You wrote the insert once, and it sat there. Now a coding agent rewrites a checkout flow, a signup, a settings page, and the line that records the event rides along with the change. The agent is good at logic and indifferent to side effects. The write that records an event is a side effect. It gets renamed, moved, or dropped, and the PR still passes review because the feature works.

The shift is that instrumentation is now rewritten constantly, by tools that do not know which line fed which chart, and no one is reviewing that specific thing.

A check on the pull request, not a dashboard three weeks later

Skene runs as a GitHub Action on every pull request. It reads the repository, indexes every event your app writes, and reads your Supabase schema for the tables those events land in. When a pull request changes a file that writes events, Skene compares the new state against that baseline and checks that each event still fires and still matches the table it belongs to.

A removed write, a renamed column, or a payload your schema cannot store shows up as a comment on the PR, naming the event, the file, and what stops being recorded. You fix it in the same commit, while the data is still recoverable, instead of finding out in a flat dashboard weeks later.

The database is the contract

We have a clear opinion about where your telemetry belongs: in your own Supabase database, not shipped off to a vendor you rent. Your schema already defines what every event is supposed to look like. The tables, the columns, the types. That schema is the contract.

Skene reads it read-only and maps each event your code writes to the table it lands in. On every pull request, and on a schedule after merge, it checks that the two still match. It moves no data and duplicates nothing. The check runs against structure, not records.

The agent should not grade its own work

Tracking that compiles is not tracking that works. The event fired. Did it land? An agent checking the instrumentation it just wrote is the conflict of interest the check exists to remove. The gate has to sit outside the tool that made the change.

That is what Skene is: the independent check in the pull request, and the record of what every event is supposed to do. It does not write your code and it does not store your data. It is the seat, not the data.

Working with design partners

We are building Skene with a small group of design partners, teams shipping fast on Supabase with coding agents and no dedicated analytics person. If that is you, and you have watched a dashboard go flat after a refactor, we would like to talk.

Try it

Add the GitHub Action, connect your Supabase project read-only, and run the first audit against the code you already have. It takes about as long as your CI does. Read the docs or open the repository to get started.