Signal sources

Contents

Open beta

Self-driving is in open beta. It's improving quickly – expect rough edges, and expect them to disappear fast.

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.

MCP is handled for you

You don't need to configure MCP servers for inbox sources manually. Once your repository is connected, research tasks can run automatically.

PostHog sources

These sources are available when the matching PostHog product has data in your project.

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

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.

Research tasks

Still have questions?

Was this page useful?