Scout examples
Contents
Self-driving is in open beta. It's improving quickly – expect rough edges, and expect them to disappear fast.
A scout can watch almost anything you land in PostHog. There are two kinds: the canonical scouts PostHog ships with, and custom scouts you create for the patterns specific to your product. This page is a catalog of both, to spark ideas for what to point a scout at.
The pocket guides walk through real scouts end to end – the report each one files, the pull request it becomes, and a one-click way to add it to your own product.
Canonical scouts
PostHog ships a fleet of canonical scouts out of the box, each watching a common pattern. You turn each one on or off per project. Each scout is just a skill you can read (named signals-scout-*) – the table links straight to its SKILL.md in the PostHog repo. Here's the full set:
| Scout | What it looks for |
|---|---|
| AI observability | Cost, latency, error, eval, and tool-usage trends and spikes across your AI traffic |
| Anomaly detection | Bursts, drops, flat-lines, and trend breaks in your most-viewed dashboards and insights |
| APM | RED-metric regressions (error rate, p95 latency, volume) and new errors per service and operation |
| Conversations | Support delivery regressions – SLA breach rates, first-response latency, backlog inflow outpacing resolution, and channel or assignment concentration |
| CSP violations | Content Security Policy violation clusters, per-directive bursts, and suspicious third-party domains |
| Customer analytics | Churn-risk shapes on named accounts – engagement cliffs, dormancy, single-threaded champions |
| Customer analytics billing and usage | Per-account product-mix shifts in usage and forecasted MRR that are masked by a stable account total |
| Data pipelines | Delivery failures across CDP destinations, batch exports, and workflows, where config and reality disagree |
| Data warehouse | Imports that quietly stop keeping their promise – failed source connections, stuck or silently stale syncs, row-volume cliffs, and failed materialized views |
| Error tracking | Error spikes, stuck loops, and fingerprint clusters, triaged by how many users they hit |
| Experiments | Validity threats like sample-ratio mismatch, plus zombie experiments running past their useful life |
| Feature flags | Evaluation cliffs, ghost flags where code still calls a flag that no longer exists, and flag debt |
| General | Cross-product correlations and any surface no specialist covers |
| Health checks | Setup health issues – no live events, outdated SDKs, missing reverse proxy, failing warehouse models |
| Inbox validation | Whether a merged fix actually held, re-measured after a deployment soak window |
| Insight alerts | Alert firings a human likely missed, especially ones the normal notification path stayed silent on |
| Logs | Volume bursts, severity-distribution shifts, service silence, and new error message patterns |
| MCP tool calls | MCP tools that need improvement – broad failure rates, retry hammering, and slow or context-bloating responses |
| Observability gaps | Coverage gaps – high-volume events with no insight, dashboard, or alert |
| Product analytics | Regressions in your funnels, retention, lifecycle, stickiness, and paths |
| Replay Vision | Whether Replay Vision scanners are still observing, and what their observations surface |
| Revenue analytics | MRR and churn shifts, broken Stripe syncs, and revenue config drift |
| Session replay | Recording capture integrity, plus rage-click and dead-click friction clusters |
| Skills store | Static, verifiable skill-authoring problems such as vague descriptions, stale file links, bloated bodies, and committed secrets |
| Surveys | NPS and CSAT regressions, plus recurring themes in open-text responses |
| Tasks | Agent task delivery health – runs failing, clustered by repo and error class, retry storms, and recurring asks that point at a product gap |
| Web analytics | Acquisition channels diverging, attribution breakage, and 404 spikes |
| Web vitals | Core Web Vitals regressions and other recent performance shifts in web traffic |
Most are specialists that watch one surface in depth; the general scout is the exception – it watches the seams between surfaces, like a deploy, then an error burst, then a conversion dip, that no single specialist would catch on its own. Browse them all in the products/signals/skills directory.
Ideas for custom scouts
You can create your own scout for anything you care about. The job is the same each time: pick a surface you wish someone was watching, write down what "worth my attention" means for it in plain English, and let the scout hold that bar for you. Some directions to steal:
| Use case | What it does |
|---|---|
| Mine any Slack channel | Sync a channel into the data warehouse and a scout reads it like any other table – a user-feedback channel, an on-call channel, even a community Discord relay. The moment it's a table, it's fair game. |
| Watch any custom event | Point a scout at any event you capture – a support event, a feedback submission, a domain-specific action – and have it turn that stream into findings. |
| Keep an eye on what you already care about | Hand a scout a curated set of your dashboards, insights, and alerts – the metrics your team checks every morning – and have it stay quiet until one moves against its own baseline. Tags work as the config surface too: tag the entities you want watched in PostHog, and untag to turn it off. |
| Let a scout maintain your dashboards, alerts, and views | Watching is half the job. Give a scout write access to the dashboards, alerts, or warehouse views it looks after, and it repairs the dead tile, retunes the noisy alert after back-testing the change, or re-runs the stale view in the same run it finds the problem. It keeps a list of what it owns, caps its changes per run, writes up every change, and hands anything that drops data or changes meaning to a person with the exact edit spelled out. The same shape keeps Replay Vision scanner prompts in step with a UI that keeps changing. |
| Give a scout your book of accounts | An account manager's accounts, resolved live from who owns what, watched for the handful of things that person should act on: a new stakeholder appearing, a sustained engagement change, a billing-page visit, a product adopted or dropped, an unanswered question in the shared channel. It files only when the owner should act, ranks by what's at stake, and lands in their Slack DM. Several account managers on one team built this shape independently within days of each other. |
| Track what customers said they would do | A scout can keep a ledger of commitments from call notes and CRM next steps, map each one to the product signal that would prove it happened, and report only movement: the commitment that landed, or the one that has gone a week with a flat signal and needs a nudge. |
| Turn a trigger into a brief | When something upstream already names a new entity, a signup that created an organization, an account that just became eligible for onboarding, a new person appearing inside an account you own, a scout can assemble the brief: usage, billing, CRM context, contacts, and a guarded look at their website, graded against your ideal customer profile and routed to whoever owns it. |
| Keep one living status report | Instead of a report per finding, a scout can keep a single report current: the pull requests that need their author right now and whose turn it is on each, or the few inbox items a person should act on next. It rewrites the same report every run and pings a DM only when something moved. |
| Predict first, then measure | A scout can hold a small world model in its memory: what it expects a metric to do next week, the hypotheses that would move it, and the observation that would settle each. It reports the prediction error rather than the number, so a surprise arrives with its likely cause attached. Good for low-volume metrics where bucket-by-bucket anomaly scoring is mostly noise. |
| Own a funnel or a journey | A scout can watch your key funnels and activation flows, flag a conversion or retention regression against the flow's own trailing baseline, and even propose the experiment to fix the weakest step. |
| Find what people asked for and didn't get | Someone searches and gets no results, filters a marketplace down to nothing, or picks a vehicle no product fits. The request succeeded, so no error fires and no funnel step drops – but the person left empty-handed. A scout can watch the empty-result rate per care type, postcode, or category, and rank the gaps by how many people hit them. Over a docs search, the same scout doubles as a content backlog: the questions you haven't answered yet. |
| Catch the broken part a stable total hides | Traffic looks flat, so nothing alarms. But one language route is dead, one content category stopped being recommended, or one entry method quietly broke. The remaining segments absorb the difference and the total never moves. A scout can watch each segment's share of the total, not only the total. |
| Get a morning digest | Most scouts stay quiet until something clears a bar. A digest scout inverts that: one report a day synthesizing its surface – your AI traffic, the day's merged PRs grouped into workstreams – where a quiet day gets a short "all green" and that's the product. |
| Turn free text into themes | Survey responses, feedback submissions, support messages: instead of forwarding every item, a scout aggregates – "these six responses all describe the same checkout bug" is one actionable finding, not six noisy ones. |
| Score what you can't query | Some metrics are judgment calls: whether a support reply resolved the question, whether generated content follows your guidelines, whether a summary sticks to its sources. A scout can judge a fresh sample on a schedule and record each verdict as a structured measurement, turning a subjective quality bar into a chartable time series. |
| Triage what already pages you | If a detector already exists – billing spike alerts, an incident pipeline, a support channel where a bot classifies every ticket – a scout can be the judgment layer on top: bundling related items into one finding, weighing who's affected, and flagging the items nobody acted on. |
| Guard your SLOs | If your team has explicit success-rate targets, a scout can score against the error budget instead of a trailing baseline – catching fast burns (an incident eating the budget right now) and slow burns (a success rate quietly creeping below target). |
| Notice when something stops happening | Error tracking only sees code that throws – it can't see silence. A scout can pair an event that should keep firing (a compliance check in CI, a scheduled automation, even your own event capture) with a heartbeat that proves the system is otherwise alive, and flag when the heartbeat continues but the expected event goes quiet. |
| Check your analytics against a second source | A capture cliff is easy to spot. A slow leak is not. Adblocker share creeps up, a consent banner changes, or a route stops firing pageviews. Everything downstream then reads the decline as a real drop in traffic. A scout can compare your PostHog numbers against a count your SDK is not in the path of. CDN analytics, server logs, and order counts from your own database all work. The finding is a drift in the ratio between the two. |
| Check every promise was kept | Some failures return a 200: a payment succeeds but the webhook never arrives, an order is placed but the fulfillment event never follows, a signup completes but the welcome email never sends. A scout can join each "promise" event to its expected fulfillment and flag when the unmatched share climbs above its baseline. |
| Watch a queue humans should be draining | Approval queues, moderation backlogs, access requests, support tickets with an SLA: a scout can match submissions to their resolutions and flag items unactioned past a soak window, a burst someone probably missed, or drift in the approval rate itself. |
| Work your issue tracker's backlog | GitHub Issues and Linear are signal sources already. Each new issue becomes a signal as it arrives. A scout adds what a source can't. It re-reads the whole backlog each run, so it catches the issue that became ready weeks after someone filed it. Give it a bar, such as unclaimed, unblocked, and scoped enough to start on. It then surfaces what is ready to pick up, limited to the labels or teams you care about. A report that clears the bar can go on through the loop and come back as a draft pull request. Note that a scout reads your last completed sync, so set the source and the scout to comparable schedules. |
| Monitor your model's verdicts | If your product ships a classifier – fraud, spam, content moderation – a scout can watch its verdict rate and confidence distribution for silent drift, and cross-reference the user feedback that disagrees with it. Model degradation never throws an exception. |
| Audit an automated judge | Where a model already makes decisions, a safety filter that blocks content, a router that decides what is actionable, a grouping step, a scout can re-judge a sample and record each verdict as a true or false positive or negative, with the failure pattern. Re-judge every rare positive and a sample of the common negatives, so the series measures the decisions that matter. The result is a precision and recall dashboard for a judge you could not otherwise evaluate. |
| Watch your AI agents like infrastructure | If your product runs a fleet of agents, an orchestrator handing work to workers, a debate loop, an outbound channel router, their task-completion lifecycle deserves the same watch a job queue gets: terminal failures and incomplete runs as a share of the runs started, delivery failures per channel, retry pressure, and approvals that operators reject by tool. This is separate from watching the LLM calls underneath for cost and latency. |
| Match what you shipped to who asked for it | A feature landed. Somewhere an account asked for exactly that in their shared channel or a support ticket. A scout that reads merged changes on one side and account asks on the other gives each account owner a concrete reason to reach out, held to an exact ask or a distinctive workflow so it never becomes a newsletter. |
| Track how AI engines see you | AI crawlers and AI-search referrals are becoming an acquisition channel of their own. A scout can watch crawler visits and AI-sourced traffic per engine, catching indexing shifts before they show up in your traffic numbers. |
| Catch bots and freeloaders | Scraper traffic that slips past standard bot filtering still leaves a shape: a pinned user agent, geographic concentration, near-zero engagement. Several teams have independently built scouts for exactly this. The same shape catches incentive abuse, such as one card that mints trial after trial and never converts. Whoever games you reuses an identifier that real customers spread thinly across. Send these findings to a person to action, never to an automated block. A false positive here lands on a real customer. |
| Hear frustration before failure | Users route around problems before your telemetry names them: manual-refresh spikes when data goes stale, a surge in FAQ or contact-page visits when something confuses, usage-cap blocks piling up before an upgrade-or-churn decision. These coping behaviors make great leading indicators. |
| Watch the physical world | Anything that lands events in PostHog is watchable – including hardware. Kiosks, wearables, vehicle fleets, connected devices: a scout can watch a fleet's heartbeat and fault events like any other stream, flagging silence where there should be a steady hum. If your product touches the real world, a scout can too. |
| Have it read your codebase | Give a scout a repo and a job: catch docs that have drifted out of date, flag a feature shipped with no instrumentation, spot a third-party API your code pins that's headed for sunset, or run a static-analysis tool over the last week's diffs. |
| Cross-reference code with PostHog | Some signals only exist in the overlap: a fully-rolled-out feature flag whose key still litters the codebase is cleanup work, but only a scout that reads both the flag's state and the repo can tell. The same shape catches insights pointing at events the code stopped emitting. |
| Dogfood your own product | If your product has an API, MCP, or agent surface, a scout can use it like a real user each run – working through realistic tasks and reporting the friction it hits first-hand, before your users do. |
| Point a scout at your scouts | A meta-scout that audits the rest of the fleet for miscalibration, plus a follow-up that re-checks "resolved" reports after a soak window to confirm the fix actually held. Two more shapes have proved useful: a daily state-of-the-fleet digest (what was created, paused, or edited, and which scouts' reports people actually open), and a reviewer that holds a family of scouts' reports to a contract, every finding either carries an action PostHog can take or says exactly who can and how, and steers the emitting scouts with notes rather than editing them. |
| Arm one fix at a time | When the inbox already holds more findings than the software factory should take at once, a dispatcher scout picks one per run: it re-confirms the finding is still live, checks the fix sits inside an agreed set of files or change shapes, and files a report carrying the implementation contract and the acceptance check, so the draft pull request that opens has something to prove. Detection stays with the scouts that found the problem. |
The common thread is that a scout isn't limited to product analytics. Any source you land in PostHog – a warehouse table, a Slack relay, a third-party feed – becomes something a scout can watch.
Make your own
You don't write a scout by hand. In PostHog Desktop, open the scouts page and pick the "Make a scout" suggestion: it scans your project and proposes custom scouts grounded in your actual data. You can also ask any agent connected to the PostHog MCP to build one – a prompt like this works:
Once a scout exists, run it on demand to see what it surfaces before enabling it.
Every idea above is a variation on a small set of reference shapes – anomaly watcher, watchlist, warehouse-backed source, daily digest, maintainer, owner-scoped book, and so on. The scout patterns cookbook catalogs them all, with the discriminator, memory, and gotchas for each – it's what the authoring agent reads, and it's worth a skim if you're deciding what to build.
For a deep dive – two real scouts traced end to end, with a walkthrough video – read What is a scout?.
Next step
See what a scout emits when it finds something.