Send PostHog events and flag changes to Sazabi

Last verified on Nov 8, 2026.

PostHog records what users did. Your logs record what the system did. A drop in sign-ups after a release usually has a cause on one side and a symptom on the other, and teams end up lining up timestamps by hand across two tools.

Sazabi, the AI-native observability and security platform, accepts PostHog events as records beside your service logs. It can also let the agent query PostHog itself, so a question about a flag and a question about an error can be asked in the same thread.

What each source sends

PostHog connects four ways, and they behave differently.

• Webhook destination. PostHog's Data Pipeline posts each matching event to Sazabi as JSON. On the connected-account path Sazabi installs and maintains an HTTP Webhook destination, which PostHog calls a hog function, for each project you select, using a personal API key with project:read, organization:read and hog_function:write. On the manual path you create it yourself and use a body with two keys, event and person. With no filter, every captured event is forwarded.
• Browser proxy. A reverse proxy you control routes posthog-js capture paths /e/, /i/ and /s/ to Sazabi instead of PostHog, while config, flag and asset traffic still goes to PostHog. It sees only browser traffic. This is the one to choose carefully, because PostHog stops receiving that capture traffic.
• MCP connector. The agent can query events and trends, browse feature flags and rollout status, review experiment results and search person and group properties. It has write access unless you connect with --read-only.
• Sandbox CLI. posthog-cli runs in the sandbox with POSTHOG_CLI_API_KEY and POSTHOG_CLI_PROJECT_ID, for source map uploads and project queries.

Questions it answers

• Did errors in the API rise after a feature flag reached more users?
• Which $pageview paths lost traffic in the same minutes a service started failing?
• Is one experiment variant seeing more failed requests than the other?
• Which distinct IDs were active when the checkout service timed out?
• Is the event stream itself healthy, or did a destination stop delivering?

A worked example: a flag rollout and a spike in 500s

PostHog's event model gives each event an event name, a distinct_id, a timestamp and properties. Experiments rely on the $feature_flag_called event and a $feature/<flag key> property. A forwarded record, abbreviated and with fictional values, carries those fields under the event key:

{
  "event": {
    "event": "$feature_flag_called",
    "distinct_id": "user-4821",
    "timestamp": "2026-11-08T10:02:41.120Z",
    "properties": {
      "$feature/new-checkout": "test",
      "$current_url": "https://app.example.com/checkout"
    }
  }
}

The rollout of new-checkout went from 10% to 50% at 10

sazabi logs ask "Compare orders-service 500s before and after 10:00 with PostHog feature_flag_called events for new-checkout"

The answer puts both streams on one timeline. If the 500 count steps up when flag calls do, the flag is the lead. If it does not, you can rule the rollout out in one question instead of ten minutes. Then, in a thread with the connector enabled, the agent can read the flag's rollout configuration. Because the connector can write, decide up front whether it should be allowed to roll the flag back, and connect with --read-only if the answer is no.

How it fits with other integrations

PostHog sits in observability tools next to Sentry, which carries exceptions rather than product events. Frontend telemetry from Sazabi's own SDK has its own page at Sazabi Browser SDK. Support context can come from Plain. See pricing for how volume counts.