Signal sources

Signal sources are what fill your inbox. A signal can be a production error, a support conversation, a Session Replay pattern, a log alert changing state, a Replay Vision scanner finding, an LLM trace regression, an insight anomaly, or an issue from an external tracker. Each source watches one of these streams and turns what it finds into work worth investigating.

Configure sources

From the inbox, open settings and configure your sources. Toggle the ones you want to enable, then follow the authentication prompts for any external services. The inbox is available across surfaces – the web app, PostHog Desktop, and Slack – and your sources stay the same wherever you open it.

PostHog sources

These sources use data from the matching PostHog products in your project. Enable the corresponding source or scout to receive findings in your inbox.

Feature flags, web analytics, surveys, data warehouse, and data pipelines use scouts. Enable the corresponding scout and keep Write signals to the inbox on. A paused scout or a scout in dry run does not write findings to the inbox.

Endpoints sends signals directly when an execution fails or a breakdown exceeds its limit. These signals require an enabled Endpoints source configuration.

• Error trackingNew exceptions, reopened issues, and error volume spikes.
• SupportActionable items from conversations.
• Session replayUX friction, unusual behavior, rage clicks.
• LogsLog alerts that fire or break due to threshold breaches.
• Replay VisionScanner findings, plus each scanner's signal, report, and pull request counts.
• AI ObservabilityFindings from your LLM traffic.
• Product analyticsInvestigated anomalies from your insights.
• Feature flagsEvaluation cliffs, ghost flags, distribution shifts, and flag debt.
• Web analyticsChannels, entry paths, and referrers that diverge from their own baseline.
• SurveysScore regressions, abandonment spikes, and recurring themes in open-text answers.
• Data warehouseFailed source connections, stale or stuck syncs, and materialized views that stop refreshing.
• Data pipelinesDestinations, transformations, batch exports, and flows where delivery stops matching the config.
• EndpointsRuns that fail, and breakdowns that hit their limit.
• Health checksOutdated SDKs, proxy gaps, ingestion warnings, broken data models, and more.

Replay Vision scanners can send their findings into Signals. Open a scanner to see how many signals it has emitted, how many reports those signals contributed to, and how many pull requests were opened or merged. Reports can combine signals from several scanners and other sources, so these counts show the scanner's contribution, not sole ownership of a report.

External sources

External sources pull issue context into the same inbox queue as your product signals. Connect any of these via the data warehouse and the inbox surfaces actionable items for research.

Search analytics

Search-performance opportunities from connected analytics sources. The inbox identifies pages that rank and receive meaningful impressions but have unusually low click-through rates, then surfaces the query, landing page, impressions, clicks, CTR, and average position for investigation.

• Google Search Console

Issue trackers

New issues from connected project management and issue tracking tools. The inbox starts a research task to find related code and decide whether a fix is possible.

• GitHub Issues
• Jira
• Linear
• GitLab
• Gitea
• Shortcut
• pganalyze

Comment back on GitHub issues

If you use GitHub Issues as a source, you can let PostHog reply on the issue. In the inbox settings, under PR generation, turn on Comment back on GitHub issues. When an issue contributes to a report and that report becomes ready, PostHog adds a comment to the issue with a link to the report. If an issue joins the report later, it gets a comment too.

PostHog comments through the project's GitHub App connection, not through the data source. Connect GitHub, and make sure the App can access each repository that has issues. A source that authenticates with a personal access token is not enough. Without the App connection, PostHog adds no comment and shows no error.

This setting is off by default, because the comment is public. Everybody who watches the issue can see that PostHog started work. The comment tells readers that PostHog researched the issue, and asks them to check before they start a fix. It also gives a link to the report. The comment does not contain the title of the report or the research, and the report itself stays behind your project's access controls.

PostHog does not comment on a closed issue, a locked issue, or a pull request.

Support / helpdesk

Customer support tickets and conversations. The inbox turns actionable bug reports and feature requests into researched implementation work.

• Zendesk
• Freshdesk
• Freshservice
• Front
• Gorgias
• Kustomer
• Dixa
• Plain

Error tracking

Errors and exceptions from external error monitoring services. The inbox surfaces new errors and error patterns for investigation.

• Sentry
• Rollbar
• Bugsnag
• Honeybadger
• Raygun

Security scanners

Security vulnerabilities and findings from code scanning tools. The inbox prioritizes actionable security issues.

• Snyk
• SonarQube
• Semgrep
• Rapid7 InsightVM

Product feedback

Feature requests, ideas, and product feedback from feedback management platforms.

• Featurebase
• Frill
• Aha
• UserVoice
• Productboard
• Canny
• AskNicely
• Retently

Reviews

App store and product reviews. The inbox identifies actionable feedback from user reviews.

• Appfigures
• AppFollow
• Judge.me

Steer a source with guidance

A source does not have to process everything the same way. You can give a source guidance: rules in plain language that tell the agent what matters to your team and what to skip. The agent reads the guidance when it decides which new records become signals.

To add guidance, open the inbox settings, find the source, and click Add guidance. Write it like a note to a teammate. For example:

- Skip issues with the `skip-self-driving` label. We scope and build those ourselves.
- Always keep issues from members of our GitHub organization.
- Ignore tickets about refunds. The finance team handles those.

For issue trackers, the agent also sees the metadata of each record, such as the labels and the author of a GitHub issue. This lets you use a label as a per-issue switch. For example, a developer who wants to build a large change themselves adds skip-self-driving to the issue, and PostHog does not research it or open a pull request for it. You can also do the opposite: "Only keep issues with the self-driving label."

Some things to know:

• Guidance applies from the next sync. Records that are already signals or reports do not change.
• An AI model applies the guidance, so treat it as a strong filter, not a guarantee. If the check fails, PostHog keeps the record.
• Not every source supports guidance yet. A source that supports it shows the Add guidance button on its card.
• Agents can set guidance too. Through the PostHog MCP, an agent can read the source with inbox-source-configs-list and change the steering key of its config with inbox-source-configs-partial-update. The update replaces config as a whole, so keep the other keys.

To steer scouts instead of sources, leave a scout note.

What happens next

Related signals don't each become their own task. As signals arrive, the inbox deduplicates them and groups related ones, so a signal from a support conversation, a matching error-tracking issue, and a session-replay pattern collapse into a single report rather than three. That way you deal with one customer-facing problem, not scattered noise.

Once a report exists, research starts if the source is enabled. The research agent connects it to your codebase, checks user impact, and marks the report as Actionable when a code fix is possible.

From there, you can review the report, ask for more research, let an implementation agent open a pull request, or audit the agent log to see exactly what it read and why.

Next step

See how the inbox researches each report.