Chapter 05
Querying exceptions
Now that Twig's engineers capture high quality exceptions, they can query them for analysis.
Here are ways Twig's engineers use other PostHog events to understand the impact of issues in error tracking.
Each check below has a prompt to give an agent on Learn Error Tracking with your agent.
Join exceptions to the rest of Twig's data
PostHog keeps Twig's events in one context warehouse with persons, groups, sessions, and the tables an app can sync from other tools, like Zendesk. HogQL queries all of it together, so anything sent to PostHog can be joined to Twig's exceptions.
The engineers want to know which issue to fix first. The exception alone can't tell them, but each one carries the same context as Twig's other events:
- Which guest hit it, in
distinct_idand their person properties. - Which host's stay it was, in
$groups. - Which session it happened in, in
$session_id, which links to the replay. - Which page it happened on, in
$current_url. - Which flag variant the guest saw, in
$feature/<flag-key>.
Using these clues, Twig's engineers can piece together a more complete story.
Issues and exceptions lists every property PostHog sets.
Rank issues by bookings at risk
Hosts pay Twig a monthly fee, which the engineers sync from Stripe as each host's mrr. They rank issues by the MRR of the hosts they hit. An issue that hits high-MRR hosts can matter more, even with fewer occurrences Fig. 1.
Book stay fails · 620 exceptions
$48,000Payout statement fails · 180 exceptions
$16,000Stay search times out · 9,000 exceptions
$4,000mrr
This joins exceptions to hosts on $groups:
| Source | What it adds |
|---|---|
$exception | The hosts each issue hit |
groups | What each host pays, from its mrr property |
The Errors in paying hosts scout runs a related check every day. It reports issues concentrated in paying hosts.
Check whether an error makes guests leave
To see whether an error makes guests leave, the engineers check three things:
- Funnels. The engineers build a funnel of booking a stay on Twig, with its graph type set to historical trends, to see whether conversion fell when the error appeared Fig. 2. They break it down by the issue's cohort, created from the issue page, to compare people who hit the error with people who didn't.
- Retention. They filter a retention insight to the issue's cohort and compare it with all users. If people who hit the error come back less, the error is driving churn.
- Session drop-off. They check whether people did anything within a minute of each error. Some sessions end anyway, so they compare each issue with the overall drop-off.
300 fewer confirmed bookings per day
Clicked Book stay: 1,000/dayConfirmed: 800/day to 500/day
The session drop-off check joins exceptions to the events that followed on $session_id:
| Source | What it adds |
|---|---|
$exception | When the error fired |
$pageview and Twig's named events, like twig_stay_viewed | Whether the guest kept going |
Watch what guests saw
When an error makes guests leave, the engineers watch their sessions to see what happened.
This joins exceptions to recordings on $session_id:
| Source | What it adds |
|---|---|
$exception | The error and when it fired |
session_replay_events | What the person saw and did |
Start from one host's errors
Triage can also start from a host. When a host reports a problem, the engineers rank every issue on that host's stays by how many guests it impacts Fig. 3. In the issue list, that's the host as a filter, sorted by Users.
Book stay fails · 314 exceptions
186Payout statement fails · 41 exceptions
27Stay search times out · 2,840 exceptions
2users
This joins exceptions to hosts on $groups:
| Source | What it adds |
|---|---|
$exception | Each issue and how many guests it impacts |
groups | Which host's stays those guests were on |
Find the errors behind support tickets
Guests and hosts reach Twig's support in Zendesk, which the engineers sync to PostHog. A ticket with an error behind it points at a bug they can fix.
This joins tickets to exceptions on the session ID in each ticket's replay link:
| Source | What it adds |
|---|---|
A tickets table, like zendesk.tickets | What the customer reported |
$exception | The error behind it |
Reach the guests an error hit
Once the engineers fix an issue, they tell the guests it hit, or survey them. They create a cohort from the issue page, then duplicate it as a static cohort to target them with a survey or flag.
This joins exceptions to people on distinct_id:
| Source | What it adds |
|---|---|
$exception | The issue each person hit |
persons | Who they are, so the team can reach them |
Catch new errors in experiments
When Twig ships a change as an experiment, the engineers add $exception as a secondary metric to compare errors across variants.
To see when errors started, they chart each variant's error rate Fig. 4. With an uneven split, they compare a ratio, like exceptions per pageview, so a variant on 5% of traffic compares fairly with one on 95%. The Feature Flags pocket guide covers running the experiment.
Control
2% of sessions hit an error
New booking form
2% to 8% of sessions hit an error
This joins exceptions to variants on $feature/<flag-key>:
| Source | What it adds |
|---|---|
$exception | Errors in each variant |
$pageview | Traffic in each variant, for the rate |
Track crash-free sessions
Twig is a web app, so the engineers track stability as the share of sessions without an unhandled exception.
This joins sessions to unhandled exceptions on $session_id:
| Source | What it adds |
|---|---|
sessions | Every session |
$exception with $exception_handled set to false | Which sessions hit an unhandled exception |
To rank your issues by the revenue they put at risk, give an agent the revenue skill Fig. 5.





