Use case
Prioritise with numbers instead of whoever sounds most certain
Someone says customers keep hitting this, with total conviction and no numbers. Nobody can check it in the next thirty seconds, so the room defers and it gets built. Connect PostHog or Sentry and the checking takes no time at all, because the number is already on the page before the claim is made.
Confidence is not evidence, but it wins the room
In a planning meeting a specific-sounding claim with nothing behind it beats a careful one with a source, because looking it up is a tangent nobody wants to take. So the loudest read on what customers want becomes the roadmap. More rigour in the meeting will not fix it. Having the number already there will.
What it actually looks like
Sprint planning. Six things competing for two developers and a fortnight.
10:00am
Someone makes the case for rebuilding the onboarding flow. "Customers keep dropping off." No numbers, said with total confidence.
Old way
Nobody can check it inside the meeting. It goes in the sprint. Two weeks of work on a hunch.
10:01am
Now: the spec Spectr wrote for that item already quotes Sentry - 412 occurrences of one checkout error in the last 30 days, as of 14 August. And PostHog survey responses mentioning the same screen.
10:04am
The onboarding claim has no number behind it. The checkout error has 412. The room can see both.
10:06am
Checkout goes in this sprint. Onboarding goes on the list to get some data on first.
Two weeks later
Checkout errors drop. Because the number was dated, you can tell it actually moved rather than assuming.
Two weeks of developer time spent on a hunch has turned into two weeks spent on the error with 412 occurrences behind it - decided in six minutes, with nobody having to win an argument.
Errors from either tool, or both
PostHog and Sentry are tracked separately, one snapshot each, each one naming where it came from. Sentry contributes unresolved issues from the last 30 days across every environment, plus a daily trend. PostHog contributes grouped errors, survey feedback and which feature flags are live. If one of them breaks, you still have the other.
The numbers come with a date on them
When Spectr writes a spec, each provider's figures go in as their own block, naming the tool and the window covered. "Sentry reports 412 occurrences in the last 30 days, as of 14 August" is something a person can go and check. "Our monitoring shows this is common" is not. Anything that is only true as of a moment says so.
Nothing personal is stored
Counts only. Every quote is stripped of emails and identifiers before it is saved, and on the Sentry side the code path is stripped too, because a code path can carry a customer id. This is built in, not a setting you have to find.
Read-only, always
Spectr never writes to PostHog or Sentry. It cannot resolve an issue, change an alert or flip a flag. It reads, and it only talks to the official cloud hosts.
Works with
Frequently asked questions
Can I connect both PostHog and Sentry?
Yes, and they stay separate - one snapshot each, combined only when you read them. Every block in a generated spec says which tool it came from.
Does this work with self-hosted PostHog or Sentry?
No, cloud only, and deliberately. Our server calls the provider with your token, so accepting any address you typed in would be a way to make our infrastructure call somewhere it should not.
How current are the numbers?
They refresh on demand, and re-sync if they have gone stale before a spec is generated. Every figure is shown with the date it was taken so you always know how old it is.
Also worth reading
See it on your own project
Free plan available - five spec sheets a month, two seats, no card required. 30-day free trial on Starter.
Free plan available. 30-day free trial on Starter.