Observations

Each scanner has an Observations tab listing every observation it's produced. Click into one to open the detail view: the structured result, the model's reasoning (with clickable citations that jump the embedded player to the cited moment), and the prompt that produced it – frozen even if you've since edited the scanner.

Observations also surface in the replay player: the observations dock at the bottom of the player lists everything scanners have found about the session you're watching, and is where the Scan this recording action lives.

To judge whether the results are right – and improve the scanner from that judgment – rate observations on the scanner's quality tab.

Observations move through a small state machine:

pending → running → succeeded | failed | ineligible

• succeeded – terminal. The structured result is saved and a $recording_observed event is emitted.
• failed – terminal. The detail view shows an error reason. See troubleshooting for what each failure kind means.
• ineligible – terminal. The session can't be analyzed (no recording, too short, no events, etc.). Doesn't count against your quota. See running scanners.

Succeeded, pending, and running observations spend credits; failed and ineligible ones don't. A failed observation can be retried from its detail page (or from its card in the replay player), which replaces it with a fresh scan of the same recording.

Querying observations as events

Every successful observation is captured as a $recording_observed event in your project, so you can build insights, dashboards, and alerts on top of Replay Vision output using PostHog's SQL.

Event properties

The timestamp on the event is the moment the observation completed, not the moment the underlying recording was captured.

SQL recipes

Monitor: count flagged sessions over time

Sessions a "Dead-end pages" monitor flagged yes, daily, over the last week:

SELECT
    toStartOfDay(timestamp) AS day,
    count() AS flagged_sessions
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_name = 'Dead-end pages'
  AND properties.scanner_output_verdict = 'yes'
  AND timestamp > now() - INTERVAL 7 DAY
GROUP BY day
ORDER BY day

Monitor: true rate (flagged / total)

The proportion of observed sessions a monitor flagged yes:

SELECT
    countIf(properties.scanner_output_verdict = 'yes') AS flagged,
    count() AS total,
    flagged / total AS true_rate
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_name = 'Dead-end pages'
  AND timestamp > now() - INTERVAL 30 DAY

A gradually rising true rate is often a more useful early-warning signal than the absolute count.

Classifier: top tags

Most common intent tags from a classifier:

SELECT
    arrayJoin(JSONExtract(properties.scanner_output_tags ?? '[]', 'Array(String)')) AS tag,
    count() AS sessions
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_name = 'User intent'
  AND timestamp > now() - INTERVAL 7 DAY
GROUP BY tag
ORDER BY sessions DESC

Scorer: distribution

Histogram of frustration scores:

SELECT
    toInt32(properties.scanner_output_score) AS score,
    count() AS sessions
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_name = 'Frustration score'
  AND timestamp > now() - INTERVAL 7 DAY
GROUP BY score
ORDER BY score

For a percentile view:

SELECT
    quantile(0.50)(toFloat64(properties.scanner_output_score)) AS p50,
    quantile(0.90)(toFloat64(properties.scanner_output_score)) AS p90,
    quantile(0.99)(toFloat64(properties.scanner_output_score)) AS p99
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_name = 'Frustration score'
  AND timestamp > now() - INTERVAL 7 DAY

Summarizer: recent summaries

Latest summaries from a summarizer scanner:

SELECT
    timestamp,
    properties.session_id AS session_id,
    properties.scanner_output_title AS title,
    properties.scanner_output_summary AS summary
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_name = 'Session summary'
ORDER BY timestamp DESC
LIMIT 50

Summarizer: top friction points

Summarizers also emit a scanner_output_friction_points array naming the blockers and frustrations the user hit. Unnesting it gives you a ranked list of what's tripping people up:

SELECT
    arrayJoin(JSONExtract(properties.scanner_output_friction_points ?? '[]', 'Array(String)')) AS friction_point,
    count() AS sessions
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_name = 'Session summary'
  AND timestamp > now() - INTERVAL 7 DAY
GROUP BY friction_point
ORDER BY sessions DESC

Cross-scanner: spend by scanner

Each event carries a credits property with the observation's cost (1 credit = $0.01), so spend is just another query. This is the same data behind the Usage tab on the Replay Vision home:

SELECT
    properties.scanner_name AS scanner,
    sum(toFloat64(properties.credits)) AS credits
FROM events
WHERE event = '$recording_observed'
  AND timestamp > now() - INTERVAL 30 DAY
GROUP BY scanner
ORDER BY credits DESC

Cross-scanner: filter only high-confidence verdicts

SELECT *
FROM events
WHERE event = '$recording_observed'
  AND properties.scanner_output_confidence > 0.8
ORDER BY timestamp DESC

Confidence is self-reported, so this is a heuristic, not a guarantee – but it's often a useful filter for downstream automation.

Scanner impact and cohorts

Each scanner tracks its impact: how many sessions and users its findings affected over a trailing window (default 30 days). These counts appear on the scanner's Overview tab.

What counts as "affected" depends on the scanner type:

Creating cohorts from scanner results

You can save a scanner's affected users as a static cohort with one click. The cohort is a snapshot at creation time and won't live-update as new observations come in.

For monitors, click Save as cohort in the impact panel. For classifiers, each tag has its own cohort button.

Cohort creation is capped at 10,000 users per request. If your scanner has more affected users, consider narrowing the trailing window or creating multiple cohorts over different time ranges.

Use these cohorts anywhere cohorts work in PostHog: funnel breakdowns, retention analysis, survey targeting, or experiment exclusion.

Wiring observations into the rest of PostHog

Insights and dashboards

The recipes above all become insights by saving the query. From there they go on dashboards like any other insight.

Alerts

Alerts on an insight built from $recording_observed give you a notification when the metric crosses a threshold – e.g. "alert me when the dead-end true rate over the last hour exceeds 5%." If you'd rather get the finding itself – the AI narrative and links to the matching sessions – on a schedule or when a condition is met, use scanner digests and alerts instead.

Joining to other PostHog data

Because $recording_observed events live alongside everything else in your project, you can join them to anything – pageviews, custom events, person properties, cohorts. A useful pattern: find the events the user fired before the moment a monitor flagged them, grouped by URL.

SELECT
    pv.properties.$current_url AS url,
    count(DISTINCT pv.properties.$session_id) AS sessions
FROM events pv
INNER JOIN events ro
    ON ro.properties.session_id = pv.properties.$session_id
WHERE
    pv.event = '$pageview'
    AND ro.event = '$recording_observed'
    AND ro.properties.scanner_name = 'Dead-end pages'
    AND ro.properties.scanner_output_verdict = 'yes'
    AND pv.timestamp BETWEEN ro.timestamp - INTERVAL 5 MINUTE AND ro.timestamp
GROUP BY url
ORDER BY sessions DESC

The join is by session_id. From there it's the same SQL you'd write for any other event.