PostHog

Connecting PostHog makes production errors a signal source. Each new active error-tracking issue in your PostHog project arrives in nima as one signal, so what is breaking competes for the roadmap alongside what customers ask for. nima only reads error tracking. It never resolves, assigns or comments on a PostHog issue.

Connect PostHog

Connecting PostHog links one PostHog project to your workspace through PostHog's OAuth screen. A workspace owner or admin does it from Integrations, the home screen of the web app. Members cannot manage integrations.

1. Open Integrations and select the PostHog card.
2. Choose Connect PostHog. You land on PostHog's authorization screen.
3. Review the permissions and authorize. You return to nima connected, and nima queues a first sync right away.

nima connects the project that is current for you in PostHog, so switch to the right project before you start. A workspace has one PostHog project, and connecting again replaces the existing connection. US and EU PostHog accounts both work.

nima asks for two scopes and writes nothing back:

What arrives from PostHog

nima creates one signal per active PostHog error-tracking issue, once. PostHog already groups every occurrence of the same fault into an issue, and nima inherits that grouping.

• One signal per issue, ever. An existing signal is never updated later, and a resolved issue that comes back does not create a second signal.
• Content. The signal text holds the issue title and description, occurrence, session and affected-user counts, first and last seen, PostHog's severity (low, medium, high or critical), the library, source and page the error came from, up to five stack frames with your own code first, and a link to the issue.
• No redaction. nima does not scrub the issue text. Whatever PostHog holds in the title, description and stack frames is stored as it is.
• Weight and origin. The signal's origin is internal, and PostHog counts with weight 0.8 when nima ranks a beacon.
• No urgent-incident path. PostHog signals carry no incident evidence, so they never trigger the fast path that marks a beacon ready immediately. They group and rank like any other signal.

An owner or admin can re-read the issue as it stands now, with its latest event and top frames, through the get_signal_source tool. See get_signal_source.

PostHog sync timing and limits

nima pulls new PostHog issues every 10 minutes. There is no schedule setting.

• First pull. After you connect, nima looks back 7 days. An issue PostHog first saw before that stays in PostHog, even if it recurs later. Reconnecting without disconnecting keeps the previous sync point instead of looking back 7 days again.
• Later pulls. Each run reads from the last successful sync, with a 5-minute overlap.
• Per-run cap. A run reads at most 500 active issues (5 pages of 100), newest first. When more than 500 new issues are waiting, nima keeps the same starting point for the next run, so each run reads the newest 500 again. Older issues past the cap are not picked up while the backlog stays above 500.
• Active issues only. Resolved issues are not read.
• No volume floor. There is no severity or occurrence threshold. A noisy project can produce up to 500 signals on its first pull, so check the project before you connect.
• Sync now has no UI. An owner or admin can queue an immediate pull with POST /v1/posthog/app/sync, which answers 202 with { "queued": true }, and read state with GET /v1/posthog/app/status. Both need a signed-in owner or admin session. API keys and OAuth tokens are refused, and the web app has no button for them.
• Pausing does not stop syncing. The On/Paused switch on the card only changes its label. To stop PostHog signals, disconnect.
• Access failures. If PostHog rejects nima's access for good, nima stops syncing that workspace and marks the connection invalid until you reconnect.

Disconnect PostHog

Disconnecting PostHog asks PostHog to revoke nima's tokens (best effort; you can also revoke the app from PostHog) and deletes the stored connection. A workspace owner or admin does it from the PostHog card on Integrations, or with DELETE /v1/integrations/posthog from a signed-in session.

Signals nima already created stay, with their links to the PostHog issues. nima can no longer re-fetch the originals through get_signal_source.