Connecting PostHog to n8n: automatically alert on a conversion rate drop

A PostHog dashboard doesn't notify anyone when it changes: a conversion rate that drops on a Friday evening can go unnoticed all weekend if nobody thinks to reopen the funnel. This guide shows how to query PostHog's Query API (HogQL) from n8n, compare a conversion rate to its recent trend, and trigger an AI-enriched Slack alert as soon as a real drop appears — the same principle as the SEO traffic decay detection already covered on this blog, applied here to a product funnel instead of organic traffic.

Two ways to connect PostHog to n8n

n8n ships a native PostHog node, but it's mainly built to capture events into PostHog from another tool — logging a Stripe conversion, a Supabase signup, or any business action that has no native front-end tracking. It's not the right tool for reading aggregated data.

To query a funnel or run a HogQL query, you need an HTTP Request node calling PostHog's Query API directly — the same workaround already needed for Anthropic prompt caching or the OpenAI/Anthropic Batch APIs: a platform's finer-grained features rarely come with a ready-made dedicated node.

Creating and securing the personal API key

Authentication runs through a personal API key, created in PostHog's user settings with the "Query Read" permission — no need to grant write or admin rights for this workflow. Store it in an n8n credential of type "Header Auth" (Authorization: Bearer <key>) rather than hardcoding it in a request body; our guide on securing API credentials covers this best practice, which applies to any third-party service called through HTTP Request. Also double-check your instance's subdomain (us.posthog.com, eu.posthog.com, or your self-hosted instance URL): a valid key on the wrong region returns a 401 that looks, misleadingly, like a credential problem.

Building the HogQL query

The POST /api/projects/:project_id/query/ endpoint accepts a HogQL query, PostHog's own SQL dialect that queries the events table directly. To track a checkout funnel day by day:

{
  "query": {
    "kind": "HogQLQuery",
    "query": "SELECT toDate(timestamp) AS day, countIf(event = 'checkout_started') AS started, countIf(event = 'checkout_completed') AS completed FROM events WHERE timestamp >= now() - INTERVAL 8 DAY GROUP BY day ORDER BY day"
  }
}

By default, the API caps the response at 100 rows — more than enough here, but add an explicit LIMIT as soon as a query can return more, to avoid an unexpected pagination surprise on any other use of the same endpoint.

Building the n8n workflow

The pipeline reuses a structure already proven on this blog for scheduled monitoring:

1. Schedule Trigger — a daily run, early morning to cover the previous full day; see the guide on the Schedule Trigger node and timezones to align the run time with your team's timezone rather than PostHog's default UTC.
2. HTTP Request — the HogQL call above, with retries configured; check the guide on HTTP Request retries and timeouts for projects with a high event volume where latency can spike.
3. Code node — compute the daily conversion rate (completed / started), then compare the last complete day to the 7-day rolling average of the preceding days — exactly the logic already used to detect an SEO traffic decline rather than a single bad-looking number.
4. IF — fire the alert only when the gap exceeds a relative threshold (say, −20% versus the rolling average), to filter out the natural noise of a lower-volume funnel.

Generating a contextualized alert with an LLM

A raw alert ("checkout conversion: −27% vs 7-day average") leaves the team to do all the interpreting. An AI node downstream, wired to Claude or GPT following the method in our Claude/GPT to n8n connection guide, can turn the raw numbers into an actionable message and send it using the pattern already documented for human approval via Slack:

"Checkout conversion dropped from 4.1% to 3.0% yesterday (−27% vs the 7-day rolling average), on stable traffic volume. The drop is limited to mobile visitors. Check first: a recent change to the mobile payment form, or a performance regression on that step."

This level of synthesis turns a dashboard alert into an actionable ticket, without anyone needing to reopen PostHog to gauge how serious the issue is.

The real-time alternative: PostHog's webhook destinations

PostHog also offers native webhook destinations (under Data pipelines), which push every event matching a filter directly to an HTTP endpoint — an n8n Webhook Trigger in this case. That's useful for reacting in real time to one specific event, say every payment_failed with a given error code. But a single event says nothing about a trend: the scheduled HogQL query remains the only way to detect that a rate has dropped over a time window, which is the point of this guide. In practice, the two approaches combine well: webhooks for individual critical incidents, scheduled HogQL for trend monitoring.

Concrete use cases

• E-commerce: cart → checkout funnel, alerting as soon as a drop hits a specific step (not just the overall rate, by repeating the same query per step).
• SaaS: signup → activation funnel, broken down by acquisition channel to isolate a drop tied to a single campaign rather than a general product issue.
• Agency managing several client accounts: a variant of the workflow above, run per client with a different project_id on each iteration, feeds a weekly summary report instead of an immediate alert — same architecture, different threshold and frequency.

Pitfalls to avoid

• Comparing one day to a single other day instead of a rolling average: the natural variance of a lower-volume funnel (weekends, holidays) otherwise generates constant false positives and eventually gets real alerts ignored.
• Mixing up the PostHog project's timezone with the team's: toDate(timestamp) groups in UTC by default; see our Luxon guide on dates and times in n8n to convert correctly before grouping by day.
• Over-granting the API key's permissions: a "Query Read" key is enough for this workflow; never create a key with write access for a simple monitoring job.
• Forgetting the current day is incomplete: comparing a partially-elapsed day to an average computed on full days systematically skews the result toward a false drop; always exclude the current day from the comparison window.

A documented practice, not a shortcut

Automating this monitoring instead of relying on a regular manual check isn't just a matter of convenience: a case study by Ahmed Raza Amir and Syed Muhammad Atif, "Evaluating Workflow Automation Efficiency Using n8n: A Small-Scale Business Case Study" (2026), measures on a comparable notification workflow an execution time cut by more than 150x versus the equivalent manual process, with zero observed errors against a 5% manual error rate — exactly the kind of repetitive, delay-sensitive task a daily funnel check is. Chaining an LLM after a data trigger, as the summary step above does, also matches a pattern already widespread across the n8n ecosystem: Yutian Tang, Yuming Zhou, and Huaming Chen, in "Characterizing Large Language Model Agentic Workflows: A Study on N8n Ecosystem" (2026), show across more than 6,000 public workflows that LLMs are overwhelmingly embedded within a broader control structure — conditional logic, external tools, communication services — rather than used alone as a simple chatbot, which matches exactly the architecture described here.

Going further

This pipeline — scheduled API call, comparison to a rolling average, contextualized AI alert — reuses the architecture already shipped in the Compliance & Audit Pack (€149), whose AI summary report workflow adapts without a rewrite to summarize a conversion drop instead of a compliance audit. If your immediate priority is instead getting your inbound communications sorted reliably before turning to product monitoring, the AI Inbox Pack (€79) remains the fastest entry point, and the Complete FlowKit Bundle (€269 instead of €347) bundles all three packs for anyone who wants to cover both needs at once.