Files one Linear issue per exception with the events the user triggered just before it, a session recording link when PostHog captured one, and a queried count of how many people hit it.
Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.
TypeError: t.workspaceId is undefined
at resolveWorkspace (assets/index-4f2a91.js:1:88214), at WorkspaceSwitcher (assets/index-4f2a91.js:1:91002), at renderWithHooks. Thrown on /settings/members three minutes into the session, with flag new-workspace-switcher active.
Using this template drops you into a guided setup. It asks exactly this, nothing else:
Connect PostHog
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Linear
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Slack
One sign-in. The agent acts through your account, scoped to what this template uses.
Triage rules
How you decide an exception matters and where it goes - the person and occurrence counts for each severity, the window you count over, the Linear team that receives issues, and the exceptions you already know about and want left alone.
Choose which agent runs it
NoClick's built-in models work out of the box — or bring Claude Code, Codex, and other coding agents on your own subscription.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
An exception with a minified stack and nothing around it is a puzzle; the same exception with the four things the user clicked before it is a bug report. This agent reads the person's event trail, runs one query to find out whether this hit one person or nine hundred, attaches a session recording where PostHog captured one, and files a single Linear issue with all of it in a fixed order. Impact is a number that came back from a query, so nobody argues about it from the shape of the error message.
We already have an error monitor. Why triage exceptions in PostHog?
Because the context lives here. PostHog knows the pages, the clicks and the flags around the exception, and often has a replay of it, which is the difference between a stack trace and a bug somebody can reproduce. If you run both tools, point this at the exceptions where nobody can work out what the user did.
Will customer data end up in Linear?
People are identified by their PostHog id, and the instructions keep emails, names and other personal fields out of the issue body. The event trail is pages and actions rather than form contents. If your events carry sensitive properties, name them in the triage rules and they stay out too.
How much extra PostHog querying does this add?
One person lookup, one short event list, one aggregate query and one recording check per exception the trigger sends, which is small next to normal ingestion. You decide how many exceptions reach the trigger in the first place. Rehearsing on the staged exceptions first shows you what a day of this looks like before you point it at everything.
Free to start. Guided setup, a test run against staged conversations, and it's live.