Use case
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.
How it works
Spectr syncs PostHog and Sentry read-only: unresolved Sentry issues and the error trend, and PostHog errors, survey feedback and feature-flag rollouts. When it drafts the next spec it quotes those numbers with the date they were true, and the Product Health page shows every project's errors in one place.
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.
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.
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.
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.
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.
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.
Anything else? Email hello@crowdlinker.com and a person will answer.
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.
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.
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.
