From 63b052b89584e7d8f254b52ef4c56f57fef1eeb5 Mon Sep 17 00:00:00 2001 From: SaraMiteva Date: Mon, 25 May 2026 20:22:37 +0200 Subject: [PATCH 1/6] Sales enablement docs for error tracking, workflows, and logs --- .../error-tracking.md | 139 ++++++++++++++++ .../how-we-position-and-sell/logs.md | 140 ++++++++++++++++ .../how-we-position-and-sell/workflows.md | 152 ++++++++++++++++++ 3 files changed, 431 insertions(+) create mode 100644 contents/handbook/marketing/how-we-position-and-sell/error-tracking.md create mode 100644 contents/handbook/marketing/how-we-position-and-sell/logs.md create mode 100644 contents/handbook/marketing/how-we-position-and-sell/workflows.md diff --git a/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md b/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md new file mode 100644 index 000000000000..386f3f48f885 --- /dev/null +++ b/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md @@ -0,0 +1,139 @@ +--- +title: Error tracking +sidebar: Handbook +showTitle: true +--- + +> **Owner:** Sara Miteva + +## Elevator pitch + +PostHog Error Tracking captures unhandled exceptions from web, mobile, and backend code, groups them into issues, and surfaces them alongside session replays, logs, feature flags, and product analytics in the same platform. Source maps, auto-assignment, spike detection, "Fix with AI" prompts, and Slack / Linear / Jira / GitHub alerts all come built-in. Generous free tier, then usage-priced per exception. + +Sentry has deeper error tracking features, like more battle-tested SDKs, longer track record, more granular grouping. PostHog wins on *context*: every exception ties to the user who hit it, the session replay of the moment it broke, and the feature flag they were on. Customers pick PostHog when they want errors linked to product behavior, not when they want pure error-tracking depth. + +## The unique belief + +PostHog's vision is a self-driving product: software that watches itself for bugs, ships the fixes, and prioritizes work by user impact, not error volume. That loop needs every error to know which user hit it. + +Most error tracking tools give you a stack trace, a frequency count, and a release tag. They don't tell you which user hit the error, what they were trying to do, or whether it matters to the business. So engineers triage by error count instead of by user impact, and waste cycles on noisy errors that don't affect anyone real. + +Every PostHog exception is a product event with the user attached. Click an error to watch the user's session replay. Filter exceptions by feature flag variant, plan tier, or revenue cohort. See the business impact next to the stack trace. Sentry has the deeper SDK coverage but doesn't know your users, while Bugsnag and Rollbar are similar with good error capture, no product context. PostHog Error Tracking is the only place where every error already knows who hit it, what they were doing, and whether it matters. + +## Who this is for + +- **Teams already on PostHog who pay separately for Sentry, Bugsnag, or Rollbar.** They're paying twice and stitching user identity by hand. +- **Customers on Sentry today who want errors connected to product behavior.** We'll cover up to 6 months of free PostHog usage during the overlap when you commit to a $20k+/year annual contract. +- **Engineering teams who want to triage by user impact, not error volume.** "This exception is breaking checkout for your top-paying customers" beats "this exception happened 200 times in 5 minutes." +- **Multi-language stacks running web + mobile + backend.** Native SDKs for Node, Python, Go, Ruby, Rails, Elixir, NestJS; iOS, Android, React Native, Flutter; plus every major frontend framework. +- **Founders and small engineering teams shipping production code.** Generous free tier; no contract negotiation to start. +- **Teams running rollouts behind feature flags.** Roll back the flag that caused the spike from the same dashboard. + +### Who this isn't for + +- Teams that need full feature parity with Sentry – Sentry has deeper SDK coverage, more mature grouping, and a longer track record. +- Teams whose primary need is iOS error tracking at full fidelity – the iOS implementation doesn't symbolicate system frames yet, and Swift crashes appear as SIGTRAP. +- Compliance-driven teams needing on-prem deployment, SOC 2 audit trails on every exception, or SIEM-grade indexing – Sentry's enterprise tier and dedicated SIEM tools are more mature here. + +## Messaging + +### Message 1: Every error already knows the user + +**Problem:** Most error tracking tools give you a stack trace, a frequency count, and a release tag. They don't tell you which user hit the error, what they were trying to do, or whether it matters to the business. Engineers end up triaging by error volume instead of user impact. + +**Solution:** Every PostHog exception is a product event with the user attached. Click an error to watch the user's session replay. Filter exceptions by feature flag variant, plan tier, or revenue cohort. See the business impact next to the stack trace. + +**Supporting features:** +- Shared `distinct_id` and `session_id` with the rest of your product data +- Click any error to open the user's session replay +- Filter exceptions by feature flag variant, cohort, or plan tier +- "Fix with AI" prompts; MCP server lets agents query exceptions from Claude Code, Cursor +- Source maps, auto-assignment, suppression rules, spike detection all built-in + +### Message 2: Drop Sentry, Bugsnag, or Rollbar + +**Problem:** Most teams pay for a standalone error tracker (Sentry, Bugsnag, Rollbar) and separate tools for everything else – analytics, replays, feature flags, logs. The error tracker sees the stack trace; the other tools have the user context. Engineers stitch them by hand every time something breaks. + +**Solution:** PostHog Error Tracking replaces standalone error trackers – same SDK coverage on the languages that matter, with the user, session, replay, and flag context already attached. No CDP middleware, no identity stitching. + +**Supporting features:** +- Native SDKs for Node, Python, Go, Ruby, Rails, Elixir, NestJS; iOS, Android, React Native, Flutter; plus every major frontend framework +- Source map upload via posthog-cli and @posthog/nextjs-config +- Contract buyout for Sentry, Bugsnag, or Rollbar on annual commit +- Alerts route to Slack, Discord, Linear, Jira, or GitHub with the user context attached +- Issue management with auto-assignment, suppression rules, and burst protection + +### Message 3: Triage errors by who they hit + +**Problem:** Every error tracking tool surfaces errors by volume – the loudest exception wins the engineer's attention. But the loudest isn't always the most important. A high-volume bug in a free trial flow might matter less than a single exception breaking checkout for your top-paying customer. + +**Solution:** Filter exceptions by user cohort, revenue, plan, or feature flag. See which issues are hitting your most valuable customers and fix those first. Roll back the flag that caused the spike from the same view. + +**Supporting features:** +- Filter exceptions by any user property, cohort, or feature flag variant +- See the customer behind every issue – plan tier, lifetime value, journey +- Spike detection with rolling baselines (5-minute buckets, configurable thresholds) +- Roll back a feature flag affecting a user cohort from the same dashboard +- Issue assignment and suppression rules to manage signal-to-noise + +## Battle cards + +### vs Sentry + +**Their approach:** The 800-pound gorilla. Sentry is no longer just an error tracker; it now ships Error Monitoring, Logs, Session Replay, Metrics, Tracing, Profiling, Uptime Monitoring, and Cron Monitoring on one platform. AI suite "Seer": debugging agent, Autofix, AI Code Review, plus a Sentry MCP server. Event-based pricing with steep volume discounts – errors drop from $0.000363 to $0.000150 per event at 20M+. Free Developer plan (5K errors, 50 replays); Team starts at $26/mo + pay-as-you-go. + +**Where PostHog wins:** +- Customer wants errors connected to **product analytics, feature flags, and experiments**. Sentry has none of these, despite their platform expansion into logs, replay, and tracing. +- Customer triages by user value, not error volume – PostHog filters by cohort, plan tier, revenue. Sentry's user context is thinner. +- Customer is product-led, not infra/SRE-led. Sentry's expansion is toward Application Observability and Real User Monitoring; PostHog's is toward product engineering and growth. +- Customer wants feature flag rollback workflows from the error view – Sentry doesn't have feature flags. + +**Honest concession:** Sentry has deeper SDK coverage, more mature grouping, a longer mobile track record, and steep volume discounts that make them cheaper at 10M+ errors. We win on context, not coverage or cost-at-scale. + +Also useful: [PostHog vs. Sentry](https://posthog.com/blog/posthog-vs-sentry) + +### vs Bugsnag and Rollbar + +**Their approach:** Mid-market error tracking specialists. Rollbar positions as *"code-first observability that connects errors, replays, and releases in one place"* – session replay shipped, MCP integration, RQL query language, Root Cause Analysis AI shipped, Rollbar Resolve AI agent (opens PRs with fixes) coming soon. Free tier: 5K occurrences + 1K replays. SOC2 + ISO27001 certified. Bugsnag (SmartBear-owned) follows a similar mid-market specialist playbook, historically strong on mobile crash reporting. + +**Where PostHog wins:** +- Customer wants errors connected to the **full product behavior stack** – funnels, retention, cohorts, experiments, surveys. Rollbar and Bugsnag are error trackers plus replay, not product platforms. +- Customer is consolidating multiple tools (error tracking + analytics + flags + experiments) into one platform – Bugsnag/Rollbar are one-or-two-product solutions. +- Customer wants feature flags as a first-class capability for rollback workflows – neither has flags. +- Customer values published, transparent pricing without quote-locked enterprise contracts. + +### vs Datadog + +**Their approach:** Part of the broader Datadog observability platform – auto-grouping, real-time alerts, AI-powered insights, suspect commits. Session Replay (15 seconds before/after frontend errors) and Exception Replay (local variable capture on backend exceptions). Jira integration, Datadog On-Call. Built for SRE and platform engineering teams already invested in Datadog APM. Scales with Datadog's per-host platform pricing. + +**Where PostHog wins:** +- Customer is product-led, not infra-led. Datadog Error Tracking sits inside a stack built for SREs; PostHog sits inside a stack built for product engineers. +- Customer wants errors connected to product analytics (funnels, retention, experiments) – Datadog has RUM and Session Replay but no product analytics layer. +- Customer can't justify the broader Datadog bill at their scale – PostHog Error Tracking ships standalone with a generous free tier. +- Customer wants feature flag rollback workflows in the same dashboard – Datadog doesn't have feature flags. + +## Objections + +### "Sentry has deeper SDK coverage, more mature grouping, and now ships session replay, logs, tracing, AI, and MCP too. What's actually different?" + +**Follow-up:** Who would own this – platform/SRE engineering or product engineering? And is the use case pure error-tracking depth, or errors tied to user behavior? + +**Answer:** Sentry has expanded dramatically beyond pure error tracking – replay, logs, metrics, tracing, profiling, AI/MCP. They've moved into Application Observability territory. If the team is platform-led and the use case is full-stack engineering observability with deep error coverage as the anchor, Sentry is the more direct fit and we should say so. PostHog's wedge is different: we don't try to win on observability features. We win on **product analytics depth** – funnels, retention, cohorts, paths, experiments, feature flags. Sentry has none of these despite their expansion. The comparison isn't "PostHog vs Sentry on error tracking" – it's "errors connected to engineering telemetry (Sentry's path) vs errors connected to product behavior (PostHog's)." + +### "We're a mobile-first app. PostHog's iOS error tracking has documented gaps." + +**Follow-up:** What's the mobile breakdown – pure iOS, pure Android, or both? Which mobile crash features are non-negotiable? + +**Answer:** Our iOS implementation has documented gaps. System frames aren't symbolicated, and Swift crashes appear as SIGTRAP without messages. The PostHog product page acknowledges it directly: *"Even our team thinks Sentry is better if you need mobile support. For now!"* Active development. If mobile crash reporting is the primary need, Sentry is the right tool today. Worth flagging: if the customer also needs product analytics on the same mobile app (session replay, feature flags, experiments, cohorts), PostHog still wins on that side – many teams run PostHog for product behavior and Sentry for mobile crashes today, then consolidate as our iOS support matures. + +### "Sentry is cheaper than PostHog at high volume – their volume discounts drop errors to $0.000150 each at 20M+." + +**Follow-up:** What's your projected error volume next quarter and next year? Is error volume the primary cost driver, or do you need replay, analytics, and flags too? + +**Answer:** True at very high volumes – Sentry's volume discounts are aggressive past 10M errors per month. If error volume is the primary cost concern and the customer doesn't care about the cross-product context, Sentry wins on price at scale. PostHog's value strengthens as the customer uses more of the platform. A useful reframe in the room: **PostHog Error Tracking standalone vs Sentry standalone** – Sentry wins on price at scale. **PostHog Error Tracking bundled with replay + analytics + flags vs Sentry + LogRocket + Mixpanel + LaunchDarkly** – PostHog wins on total stack cost easily. + +### "Customers say PostHog has noisy errors and false captures. Sentry's grouping is cleaner out of the box." + +**Follow-up:** Is the concern signal quality (too many duplicates) or quantity (too many low-priority events)? + +**Answer:** Honest: this came up in our customer research. PostHog's autocapture is broader than Sentry's, which gives more raw data but more noise. The grouping algorithm is still being improved, and the docs say so. Mitigations available today: custom fingerprinting rules, ingestion-time grouping rules, suppression rules, burst protection, `before_send` hooks for filtering, and spike detection with rolling baselines to separate real spikes from noise. If the team needs zero-tuning-required out-of-the-box quality, Sentry's grouping is more mature. If they want broader capture with manual tuning to get to signal, PostHog gets there with some setup work. diff --git a/contents/handbook/marketing/how-we-position-and-sell/logs.md b/contents/handbook/marketing/how-we-position-and-sell/logs.md new file mode 100644 index 000000000000..0a1cdc254c8b --- /dev/null +++ b/contents/handbook/marketing/how-we-position-and-sell/logs.md @@ -0,0 +1,140 @@ +--- +title: Logs +sidebar: Handbook +showTitle: true +--- + +> **Owner:** Sara Miteva + +## Elevator pitch + +PostHog Logs is a centralized log search built on OpenTelemetry. Send logs from any OTLP-compatible source (including your existing Datadog Agent) and they're searchable inside the same platform that runs your analytics, session replays, errors, and feature flags. Generous free tier, usage-priced per GB, no per-host or per-user fees. + +Datadog and New Relic are mature but expensive and built for infrastructure teams. Grafana Loki is open source but logs sit apart from your product data. PostHog Logs is OpenTelemetry-native, predictably priced at a fraction of Datadog's per-GB cost, and the only one where every log already knows who hit it. + +## The unique belief + +PostHog's vision is a self-driving product: software that watches itself for bugs and conversion drops, then ships the fix while you sleep. That loop needs three things – signals, action, and the *context* that tells which signals actually matter. Most observability tools generate plenty of signals (events, errors, latency, logs) without the product context that makes them actionable. + +Logs are the backend half of the signal layer. But most observability tools treat them as text – timestamps, severity, message, search. You find the right log, then bounce to another tool to figure out who was affected, which feature flag was on, or what they were trying to do when it broke. The signal is in the data; the *meaning* is somewhere else. + +Every PostHog log already knows the user. Click any log to jump to the user who hit it – their session replay, their plan, their journey. From there, filter on any attribute you attached at ingest. See which logs hit your top 1% of customers and which hit anonymous bots. + +## Who this is for + +- **Teams already on PostHog who pay separately for Datadog, Splunk, or Loki.** They're paying twice for storage and stitching identity by hand. +- **Customers on Datadog, Splunk, or Elastic today.** Cost is the most cited switching reason. We'll buy out the contract on an annual commit. +- **Teams standardized on OpenTelemetry.** Ingest via OTLP-HTTP from any OTel source, no proprietary agent required. +- **Engineers (or product-led teams) who want logs linked to user behavior.** Backend errors become useful when they're tied to the user who hit them. +- **Startups consolidating their observability stack.** $50k credits via the startup program. +- **Teams using the Datadog Agent for log forwarding.** Point it at PostHog with one env variable. No log pipeline rewrite. + +### Who this isn't for + +- Teams with massive log volumes needing enterprise-grade indexing, ML-driven log clustering, or year-plus retention. Datadog, Splunk, and Elastic are more mature here. +- Teams whose primary problem is Kubernetes-level infrastructure observability – PostHog is built for product-led engineering, not infra-first teams. + +## Messaging + +### Message 1: Logs that already know your user + +**Problem:** Backend errors, slow requests, and rate-limited calls only become useful when you know who hit them and what they were trying to do. Most observability tools store logs in their own identity layer, so you stitch user data across Datadog, Sentry, and your analytics tool to figure out what actually broke for whom. + +**Solution:** Every PostHog log ingests with the same user, session, and event identity as the rest of your product data. Click a log to open the user's session replay. Filter by feature flag variant, plan tier, or revenue cohort. Surface related errors from the same session. + +**Supporting features:** +- Shared `distinct_id` and `session_id` across logs, errors, replays, and analytics +- Click any log to open the user's session replay +- "Related errors" tab in log details surfaces issues from the same session within ±6 hours (when `sessionId` is attached) +- Filter logs by any user property, cohort, or feature flag variant +- PostHog AI summaries highlight patterns across logs and recommend next steps + +### Message 2: One tool for your entire debugging flow + +**Problem:** When something breaks in production, the investigation usually spans five separate tools: Datadog for logs, Sentry for errors, FullStory for replays, LaunchDarkly for flag context, an analytics tool for user history. None of them know each other. Engineers correlate identity by hand every time something breaks. + +**Solution:** PostHog Logs lives in the same platform as your error tracking, session replays, feature flags, and product analytics. Logs auto-link to the session they came from, the errors they triggered, and the flags the user was on. The side tools you kept only for connecting these dots can go. + +**Supporting features:** +- **Logs + Session Replay:** click any log to watch the user's session +- **Logs + Error Tracking:** "Related errors" tab in log details surfaces issues from the same session (when `sessionId` is attached) +- **Logs + Feature Flags:** filter logs by flag variant the user was on +- **Logs + Product Analytics:** log patterns become trends, funnels, retention insights +- Browser console logs auto-captured by PostHog JS, no extra SDK to install + +### Message 3: Pay for what you ingest, not per host + +**Problem:** Datadog, New Relic, and Splunk price logs by host, GB, retention tier, and indexing rate. Bills are unpredictable and grow faster than usage. Customers in our research consistently cite cost as the sharpest switching reason: Datadog's "sudden cost increases" and "commit to events, pay on demand if you don't hit the mark" framing keeps coming up in user interviews. + +**Solution:** PostHog Logs is per-GB only. 50 GB free per month, $0.25/GB after, with volume discounts. No per-host fees. No per-retention-tier surcharges. No per-user pricing. And because ingest runs on OpenTelemetry, your setup stays portable if you ever decide to leave. + +**Supporting features:** +- 50 GB/month free across log ingest; $0.25/GB after with volume discounts +- No per-host, per-user, or per-retention-tier surcharges +- Hard billing limits per product +- OpenTelemetry-native ingest – migrate in and out without proprietary lock-in +- Datadog Agent drop-in: change one env variable to start sending logs to PostHog + +## Battle cards + +### vs Datadog (and New Relic) + +**Their approach:** Datadog is the dominant enterprise cloud observability platform, meaning it has mature features across logs, APM, metrics, RUM, and infrastructure monitoring. Pricing is layered by host + GB + retention tier + indexing rate and famously hard to predict. New Relic positions on simpler pricing with 100 GB/month free ingest and unlimited basic users, but is still infrastructure-first. Both are built for SRE and platform teams. + +**Where PostHog wins:** +- Customer is product-led, not infra-led. PostHog Logs sits next to product analytics, funnels, retention, cohorts, and experiments. Datadog and New Relic don't have any of those. +- Customer wants logs tied to user behavior, not just hostname and pod – every log shares identity with the rest of the product data. +- Customer can't justify the bill at their volume – simple $0.25/GB after 50 GB free, no per-host fees, no per-retention-tier surcharges, published pricing not quote-locked. +- Datadog Agent drop-in lets the customer migrate with one env variable. + +### vs Grafana Loki and Grafana Cloud Logs + +**Their approach:** Grafana Loki is open-source log aggregation, the L in the LGTM+ stack (paired with Prometheus/Mimir for metrics and Tempo for traces). Grafana Cloud Logs is the managed tier – 50 GB free, AI/ML insights, Adaptive Logs for cost control, a queryless Explore Logs app, and pricing across three dimensions (process + write + retain) plus a $19/month platform fee. Sells to platform engineers running the LGTM+ stack. + +**Where PostHog wins:** +- Customer's team is product engineering, not platform engineering. Grafana's mental model is metrics-and-infrastructure-shaped; PostHog's is product-shaped. +- Customer wants logs connected to *real* product analytics (funnels, retention, cohorts, paths) and feature flags – Grafana has none of those products. +- Customer doesn't want to manage three pricing dimensions or self-host Loki. +- OpenTelemetry-native ingest works either way – no proprietary lock-in in either direction. + +### vs Better Stack + +**Their approach:** Modern OpenTelemetry-native observability bundle – logs, traces (eBPF + OTel), metrics, RUM (session replay + web vitals), error tracking, incident management, status pages, on-call. Has an MCP server and an AI SRE that brings "Claude Code with the knowledge of your infrastructure." Headline pricing claim: 30x cheaper than Datadog ($687/month for 3 TB). Offers contract buyouts for Datadog migrations. Going hard after the same buyer we are. + +**Where PostHog wins:** +- Customer wants the *full* product analytics layer – funnels, retention, cohorts, paths, journeys, experiments. Better Stack has web vitals and RUM, not the product behavior stack. +- Customer needs feature flags and experiments as first-class trigger and audience sources – Better Stack doesn't have flags or experiments. +- Customer's team is product engineering, not SRE. Better Stack's AI SRE is explicitly framed for infrastructure workflows; PostHog AI is product-context-aware. +- PostHog runs analytics, replay, errors, flags, experiments, surveys, *and* logs as one connected platform – Better Stack is observability + IRM, not product-led growth. + +## Objections + +### "You don't have distributed tracing or metrics. We need full observability." + +**Follow-up:** What's your current tracing setup, and is it integrated with your logs already, or are they separate tools? + +**Answer:** Honest – PostHog doesn't ship distributed tracing or metrics today. Both are on the roadmap, coming this summer. If full observability with traces + metrics + logs in one tool is non-negotiable today, Datadog or Grafana's LGTM+ stack is the right pick and we should say so. What PostHog *does* offer is logs connected to product analytics, session replay, error tracking, and feature flags – context layers no other observability tool ships. Many teams adopt PostHog Logs alongside an existing tracing solution and consolidate later. + +**Proof point:** Logs ingest via OpenTelemetry, so an OTel-instrumented backend can send logs to PostHog and traces wherever – the standards make hybrid setups easy. + +### "Better Stack claims 30x cheaper than Datadog and has MCP, AI SRE, and a full observability + IRM bundle. What makes PostHog different?" + +**Follow-up:** Who would own this, platform engineering and SRE, or product engineering? And is the pitch landing on infrastructure observability or product behavior? + +**Answer:** Better Stack is OTel-native, MCP-capable, does contract buyouts for Datadog migrations, and has a fuller observability bundle than ours (traces, status pages, on-call). If the team is platform/SRE-led and the work is infrastructure observability + incident response, Better Stack is the more direct fit. Where PostHog wins is when the team is *product*-led, meaning they need logs connected to funnels, retention, cohorts, experiments, and feature flag exposures. Better Stack has web vitals and RUM; PostHog has the full product behavior stack and feature flags as first-class triggers. The differentiation isn't observability features, it's the product data layer those features connect to. + +### "How does PostHog handle terabytes of logs per day?" + +**Follow-up:** What's your current daily volume, and where does the cost get painful – ingest, indexing, or retention? + +**Answer:** PostHog Logs is per-GB ingest only, with volume discounts past the 50 GB free tier. At terabyte-per-day volume the bill is predictable but real – customers usually pair PostHog with sampling (drop debug-level logs in production) or use the OpenTelemetry collector to route only the logs that need product context to PostHog. For pure-volume use cases without that need (security audit, raw archival), self-hosted Loki or an enterprise platform may make more sense for bulk volume, and PostHog Logs for the *product-relevant* slice. The product integration matters most when the log is debugging a user-facing issue, not when it's part of a compliance archive. + +**Proof point:** OpenTelemetry-native ingest lets you route logs by severity, service, or attribute to multiple destinations, PostHog for product-context logs, your existing tool for the rest. + +### "PostHog feels like a web/frontend/analytics company. Can you handle our backend logs?" + +**Follow-up:** What languages and services is the backend running, and what's the daily log volume? + +**Answer:** Analytics roots make the company look web-shaped from the outside, but Logs is actually the most backend-focused product in the bundle: OTLP/HTTP ingest works from Node, Python, Go, Java, your existing Datadog Agent, or any HTTP client. Browser console capture via PostHog JS is an *additional* feature, not the primary one. Most of the "web-focused" customer feedback in our research was about historic instrumentation maturity (web SDK shipped first), not about backend logs – the ingest infrastructure is OpenTelemetry-standard and works from any backend. + +**Proof point:** PostHog uses its own Logs product internally for backend services. The Datadog Agent drop-in means existing backend log pipelines work without rewriting. diff --git a/contents/handbook/marketing/how-we-position-and-sell/workflows.md b/contents/handbook/marketing/how-we-position-and-sell/workflows.md new file mode 100644 index 000000000000..7b81357f9862 --- /dev/null +++ b/contents/handbook/marketing/how-we-position-and-sell/workflows.md @@ -0,0 +1,152 @@ +--- +title: Workflows +sidebar: Handbook +showTitle: true +--- + +> **Owner:** Sara Miteva + +## Elevator pitch + +PostHog Workflows is an automation builder that turns any product event, schedule, or cohort change into a multi-step flow – send emails, fire Slack alerts, push webhooks, update feature flags, capture new events – all on the same data your analytics, replay, and experiments already use. Triggers and the builder are free; messages start at $0.005 per send after 10K free per channel each month. + +Zapier and Make have triggers but no product context. Customer.io and Braze have lifecycle email but need a CDP in the middle. PostHog Workflows reads the product data, acts on it, and feeds the agents that act on it – for example, [our customer Grantable replaced Zapier](https://posthog.com/customers/grantable) outright and cut workflow setup time by ~90%. + +## The unique belief + +PostHog's vision is a [self-driving product](https://posthog.com/blog/self-driving-product): software that watches itself for bugs and conversion drops, then ships the fix while you sleep. The signal layer is well-covered with errors, replays, logs, analytics. What closes the loop is what happens next. Knowing a checkout error hit your top customer doesn't matter if no one is paged. The systems that act on signals almost always live somewhere else, behind a CDP or homegrown glue. + +Workflows is the act layer. Every event, cohort change, error spike, or ticket update can trigger a multi-step flow, including sending a message and updating a person property, without leaving the platform the signal came from. PostHog AI drafts email copy today; soon, agents will design and revise workflows through MCP. + +Zapier and Make have triggers but can't see product data. Customer.io and Braze send messages but need a CDP to know what users did. PostHog Workflows lives inside the signal itself, so the action follows automatically. + +## Who this is for + +- **Teams already on PostHog paying separately for Zapier or Make.** They're paying for triggers they could get for free, and stitching identity by hand to do it. +- **Engineer-led teams building product-led growth motions.** They want to act on product events – onboarding milestones, activation drop-offs, feature usage – without a CDP in the middle. +- **B2B teams running intent-signal automation.** Triggering sales follow-ups, Slack alerts, or Linear tickets directly from product behavior, not delayed by CRM syncs. ([Croissant does this.](https://posthog.com/customers/croissant)) +- **Startups consolidating their messaging stack.** Workflows replaces Zapier + Customer.io + a CDP. +- **Customers on Customer.io, Iterable, Brevo, or ActiveCampaign for transactional and onboarding email.** Especially when most of the trigger logic already lives in product events. (Suped migrated off Customer.io.) +- **AI-native teams building agent loops.** PostHog AI already drafts email copy from a prompt; multi-turn, agent-authored workflows ship through MCP. + +### Who this isn't for + +- **Teams that need deep email infrastructure** (deliverability dashboards, sent/open/click/bounce tracking, suppression lists at scale) – Iterable, Braze, and Customer.io are more mature here. We might get there somewhere down the line. +- **Marketing teams running complex cross-channel campaigns with mature audience-segmentation tooling** – the bundle is automation-first, not marketing-platform-first. (For example, Workflows doesn't have predictive segments. At some point we might get there but right now we still aren't the best tool for this use case.) +- **Teams who only want a messaging tool and don't care about the rest of PostHog** – the bundle is the whole point. + +## Messaging + +### Message 1: Your data and your automated workflows live in the same place + +**Problem:** Most teams keep product data in one tool and run automation in another. To connect them they sync data through a CDP or stitch identities by hand across Stripe, HubSpot, and Slack. The sync breaks, the schema drifts, and the workflow fires on stale data. + +**Solution:** Workflows runs inside PostHog, on the same event stream your analytics, replay, and experiments already use. Every event, every cohort, every person property is immediately available as a trigger or an audience, without having to sync multiple tools. The data and the automation share the same identity by default. + +**Supporting features:** +- Triggers run on the same events that drive your analytics +- Trigger on feature flag exposure, experiment variants, or any other product event +- Update person state inside the workflow – no reverse data engineering needed +- 35+ destinations (Slack, Linear, Jira, GitHub, Discord, more) for fan-out +- API and MCP access for programmatic workflow management + +### Message 2: React to product behavior the moment it happens + +**Problem:** Sales finds out a customer churned a week later. Support hears about an error after a ticket comes in. Engineering learns a feature flag broke during the post-mortem. The signal is in the data the whole time, and the response is late because the data has to travel through three tools first. + +**Solution:** Workflows reacts in real time. A 404 fires a Slack alert. An error spike opens a Linear ticket. A user upgrading triggers a HubSpot update. The action happens the same second the event hits PostHog. + +**Supporting features:** +- Real-time triggers on any product event – clicks, conversions, errors, feature flag exposures +- Direct dispatch to Slack, Linear, Jira, HubSpot, Discord, and 35+ destinations +- Schedule triggers for time-based playbooks; batch triggers for cohort sweeps +- Branch on conditions, wait for events, or chain workflows together via captured events + +### Message 3: Cut three vendors down to one platform + +**Problem:** Most teams pay for several layers to move product events into the tools their team actually works in. An automation builder (Zapier, Make) to handle triggers. A lifecycle messaging tool (Customer.io, Brevo, ActiveCampaign) to send the actual emails. A CDP (Segment, Rudderstack) or hand-rolled webhooks to keep identities consistent across all of them. Three bills, six contracts, and every new destination is another integration to build. + +**Solution:** Workflows replaces all three. Trigger from any PostHog event and fan out to 35+ destinations natively: Slack alerts, Linear tickets, HubSpot updates, Discord pings, custom webhooks. ([Grantable replaced Zapier](https://posthog.com/customers/grantable) outright and cut workflow setup time by ~90%. [Suped](https://posthog.com/customers/suped) consolidated transactional email off Customer.io.) + +**Supporting features:** +- One platform for triggers, conditions, dispatches, and audience updates +- 35+ destinations natively: Slack, Linear, Jira, GitHub, Discord, HubSpot, Google Ads, more +- Webhook step for anything not covered natively +- Predictable per-send pricing; no per-user, per-MTU, or per-task billing + +## Battle cards + +### vs Zapier (and Make) + +**Their approach:** General-purpose automation builders. Zapier connects thousands of SaaS tools via pre-built integrations and per-task pricing. Make uses a visual scenario builder with more powerful branching, iteration, and data transformation primitives than Zapier. Both are built to connect tools that don't natively talk, meaning events go *into* them, events come *out* the other side. + +**Where PostHog wins:** +- The customer is already sending product events to PostHog and Workflows triggers on them directly, no separate integration needed. +- Per-send pricing is more predictable than per-task as workflow volume scales. +- Bundled with analytics, flags, and experiments means no leaving PostHog to debug a workflow. +- Identity stays consistent across the stack; workflows don't break when a user property changes. +- Grantable replaced Zapier outright and cut workflow setup time by ~90%. Croissant: *"Workflows is better for us than Zapier. It's simpler, and lets us move faster without adding another vendor to manage."* + +### vs Customer.io + +**Their approach:** Lifecycle messaging platform with mature email deliverability, drag-and-drop editor, Liquid templating. **Hybrid pricing: per-profile + per-email-send.** Essentials starts at $100/mo for 5,000 profiles + 1M emails; overage is $0.009/profile + $0.12/1K emails. Recently repositioned as AI-native with an AI Agent, MCP server, AI segment builder, and AI translator. Channels include email, SMS, push, in-app, WhatsApp, LINE, webhooks. + +**Where PostHog wins:** +- Workflows triggers on the same events that already drive PostHog analytics – no double-instrumentation, no identity drift across two systems. +- Per-send pricing (no per-profile fee) – cheaper for low-frequency, large-audience campaigns. +- Bundled with analytics, session replay, and feature flags – no four-tool stack to maintain. +- [Suped](https://posthog.com/customers/suped) consolidated transactional email off Customer.io after running both in parallel. +- The customer is already paying for PostHog and sending the same events to both. + +### vs Brevo (and ActiveCampaign, Mailchimp) + +**Their approach:** Mid-market email marketing platforms with full multi-channel reach, including email, SMS, WhatsApp, push, live chat. Per-month pricing based on email send volume (Starter from 5K emails, Professional from 150K). AI features under the Aura AI brand. Strong fit for SMB and mid-market marketing teams running email-first campaigns. Customer base includes Mont Blanc, Michelin, eBay. + +**Where PostHog wins:** +- Workflows trigger on product events, not just lists or segments, meaning the customer doesn't have to engineer their own event pipeline. +- Bundled with analytics, flags, and experiments means workflows can act on product behavior the email tool wouldn't see. +- Per-send pricing instead of per-month-volume tiers – simpler to model at scale. +- Targets product-led teams whose buyer is an engineer, not a marketer. + +### vs Iterable / Braze + +**Their approach:** Enterprise customer engagement platforms with comprehensive multi-channel reach (email, mobile, web, SMS/RCS, WhatsApp; Braze adds LINE and KakaoTalk), real-time decisioning AI suites, mature segmentation tooling, and analyst recognition (Gartner Magic Quadrant Leader). No public pricing (enterprise contracts only). Customer base: Wyndham, HelloFresh, Canva, Washington Post, Square. + +**Where PostHog wins:** +- Product-led mid-market teams who don't need a full enterprise customer engagement suite. +- Engineers who want product events as the trigger source rather than CRM events or campaign builders. +- Customer wants a working workflow this week, not after a Q3 implementation. +- Bundled with the analytics, flags, and experiments product-led teams already use. +- Per-send pricing, published openly, not quote-locked. + +## Objections + +### "Customer.io / Brevo has more mature email features – open/click/bounce tracking, suppression lists, dedicated IPs. You don't." + +**Follow-up:** Are you running serious lifecycle marketing or product-triggered messaging? What email volume are you sending monthly? + +**Answer:** True today – PostHog Workflows handles transactional and product-triggered emails well, but it isn't a full lifecycle marketing platform. Most teams using Workflows are sending behavior-triggered sequences (onboarding, activation, error alerts) where the value is in the trigger logic, not the email infrastructure. If the customer is running hundreds of thousands of monthly marketing sends with dedicated IPs and per-campaign deliverability dashboards, Customer.io or Brevo is the right tool today and we should say so. If it's product-triggered or transactional, Workflows works. + +**Proof point:** [Suped](https://posthog.com/customers/suped) consolidated transactional email off Customer.io after running both in parallel. + +### "You don't have native mobile push or WhatsApp. Iterable and Braze do." + +**Follow-up:** Do you need them shipping in the next quarter, or are they on your 12-month plan? + +**Answer:** Honest: push, SMS templates, and WhatsApp templates are still rolling out – email is the production channel today, with SMS via Twilio and webhook for everything else. If the customer needs full native push and WhatsApp shipped now, an enterprise customer engagement platform is the right pick. If they can route push through a webhook to their existing push service while we build native support, Workflows handles everything else with PostHog product data attached. The roadmap is committed and tracked publicly in our Q2 objectives. + +### "We already use Zapier – why switch?" + +**Follow-up:** How many of your Zaps are actually triggered by product behavior versus tool-to-tool plumbing? And what are you paying in monthly task volume? + +**Answer:** Zapier customers usually have two patterns. Tool-to-tool plumbing (Stripe → Slack, Calendly → HubSpot) – fine to leave in Zapier. Product-behavior-triggered automations (onboarding flows, error alerts, upgrade nudges) – that's where Workflows wins, because the events are already in PostHog. Migration doesn't have to be all-or-nothing; many teams run both in parallel before consolidating. Per-send pricing is also typically cheaper than per-task once volume scales. + +**Proof point:** Grantable replaced Zapier outright and cut workflow setup time by ~90%. Croissant framed it the same way: *"Workflows is better for us than Zapier. It's simpler, and lets us move faster without adding another vendor to manage."* + +### "Workflows is too new – how do I know it's stable?" + +**Follow-up:** Is the concern reliable execution, feature completeness, or vendor lock-in? + +**Answer:** Reliable execution is solid – Workflows runs on the same engine that powers PostHog's CDP destinations and data pipelines. GA'd in December 2025 after a public alpha and beta with hundreds of teams. Feature completeness is honestly still growing (batch triggers are in beta, push/WhatsApp templates are rolling out) and we publish the roadmap. Vendor lock-in isn't a concern: PostHog is open source, OpenTelemetry-compatible, and workflows can be managed via REST API and OAuth scopes for portability. + +**Proof point:** Grantable's onboarding email flow ran 179 times in 7 sessions without issues. PostHog runs part of its flows on Workflows and is planning full migration. From c72a9f36f245d7100761f4f510adeb421d3db31f Mon Sep 17 00:00:00 2001 From: SaraMiteva Date: Tue, 26 May 2026 22:02:02 +0200 Subject: [PATCH 2/6] Apply suggestions from code review Co-authored-by: Joe Martin <84011561+joethreepwood@users.noreply.github.com> --- .../marketing/how-we-position-and-sell/error-tracking.md | 4 ++-- .../handbook/marketing/how-we-position-and-sell/workflows.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md b/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md index 386f3f48f885..4d6d72da92be 100644 --- a/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md +++ b/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md @@ -10,7 +10,7 @@ showTitle: true PostHog Error Tracking captures unhandled exceptions from web, mobile, and backend code, groups them into issues, and surfaces them alongside session replays, logs, feature flags, and product analytics in the same platform. Source maps, auto-assignment, spike detection, "Fix with AI" prompts, and Slack / Linear / Jira / GitHub alerts all come built-in. Generous free tier, then usage-priced per exception. -Sentry has deeper error tracking features, like more battle-tested SDKs, longer track record, more granular grouping. PostHog wins on *context*: every exception ties to the user who hit it, the session replay of the moment it broke, and the feature flag they were on. Customers pick PostHog when they want errors linked to product behavior, not when they want pure error-tracking depth. +Sentry has deeper error tracking features, more battle-tested SDKs, and more granular grouping. PostHog wins on *context*: every exception ties to the user who hit it, the session replay of the moment it broke, and the feature flag they were on. Customers pick PostHog when they want errors linked to product behavior, not when they want pure error-tracking depth. ## The unique belief @@ -83,7 +83,7 @@ Every PostHog exception is a product event with the user attached. Click an erro **Their approach:** The 800-pound gorilla. Sentry is no longer just an error tracker; it now ships Error Monitoring, Logs, Session Replay, Metrics, Tracing, Profiling, Uptime Monitoring, and Cron Monitoring on one platform. AI suite "Seer": debugging agent, Autofix, AI Code Review, plus a Sentry MCP server. Event-based pricing with steep volume discounts – errors drop from $0.000363 to $0.000150 per event at 20M+. Free Developer plan (5K errors, 50 replays); Team starts at $26/mo + pay-as-you-go. **Where PostHog wins:** -- Customer wants errors connected to **product analytics, feature flags, and experiments**. Sentry has none of these, despite their platform expansion into logs, replay, and tracing. +- Customer wants errors connected to **product analytics, feature flags, and experiments**. Sentry has none of these, despite their platform expansion into logs, replay, and tracing (which we also have). - Customer triages by user value, not error volume – PostHog filters by cohort, plan tier, revenue. Sentry's user context is thinner. - Customer is product-led, not infra/SRE-led. Sentry's expansion is toward Application Observability and Real User Monitoring; PostHog's is toward product engineering and growth. - Customer wants feature flag rollback workflows from the error view – Sentry doesn't have feature flags. diff --git a/contents/handbook/marketing/how-we-position-and-sell/workflows.md b/contents/handbook/marketing/how-we-position-and-sell/workflows.md index 7b81357f9862..c131dfa46bd5 100644 --- a/contents/handbook/marketing/how-we-position-and-sell/workflows.md +++ b/contents/handbook/marketing/how-we-position-and-sell/workflows.md @@ -24,7 +24,7 @@ Zapier and Make have triggers but can't see product data. Customer.io and Braze - **Teams already on PostHog paying separately for Zapier or Make.** They're paying for triggers they could get for free, and stitching identity by hand to do it. - **Engineer-led teams building product-led growth motions.** They want to act on product events – onboarding milestones, activation drop-offs, feature usage – without a CDP in the middle. -- **B2B teams running intent-signal automation.** Triggering sales follow-ups, Slack alerts, or Linear tickets directly from product behavior, not delayed by CRM syncs. ([Croissant does this.](https://posthog.com/customers/croissant)) +- **B2B teams running intent-signal automation.** Triggering sales follow-ups, Slack alerts, or Linear tickets directly from product behavior, not delayed by CRM syncs. ([Croissant does this.](/customers/croissant)) - **Startups consolidating their messaging stack.** Workflows replaces Zapier + Customer.io + a CDP. - **Customers on Customer.io, Iterable, Brevo, or ActiveCampaign for transactional and onboarding email.** Especially when most of the trigger logic already lives in product events. (Suped migrated off Customer.io.) - **AI-native teams building agent loops.** PostHog AI already drafts email copy from a prompt; multi-turn, agent-authored workflows ship through MCP. From 1dba0cafee8d4e6c2c86ffe74547f24c402025b4 Mon Sep 17 00:00:00 2001 From: SaraMiteva Date: Tue, 26 May 2026 22:02:53 +0200 Subject: [PATCH 3/6] Update error-tracking.md --- .../marketing/how-we-position-and-sell/error-tracking.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md b/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md index 4d6d72da92be..4a27df37d9ad 100644 --- a/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md +++ b/contents/handbook/marketing/how-we-position-and-sell/error-tracking.md @@ -18,7 +18,7 @@ PostHog's vision is a self-driving product: software that watches itself for bug Most error tracking tools give you a stack trace, a frequency count, and a release tag. They don't tell you which user hit the error, what they were trying to do, or whether it matters to the business. So engineers triage by error count instead of by user impact, and waste cycles on noisy errors that don't affect anyone real. -Every PostHog exception is a product event with the user attached. Click an error to watch the user's session replay. Filter exceptions by feature flag variant, plan tier, or revenue cohort. See the business impact next to the stack trace. Sentry has the deeper SDK coverage but doesn't know your users, while Bugsnag and Rollbar are similar with good error capture, no product context. PostHog Error Tracking is the only place where every error already knows who hit it, what they were doing, and whether it matters. +Every PostHog exception is a product event with the user attached. Click an error to watch the user's session replay. Filter exceptions by feature flag variant, plan tier, or revenue cohort. See the business impact next to the stack trace. PostHog Error Tracking is the only place where every error already knows who hit it, what they were doing, and whether it matters. ## Who this is for From 947730cfc2804b099bf5b77ff9d760aacb76205a Mon Sep 17 00:00:00 2001 From: SaraMiteva Date: Wed, 27 May 2026 10:38:24 +0200 Subject: [PATCH 4/6] Update logs.md --- contents/handbook/marketing/how-we-position-and-sell/logs.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/contents/handbook/marketing/how-we-position-and-sell/logs.md b/contents/handbook/marketing/how-we-position-and-sell/logs.md index 0a1cdc254c8b..4bdce015c596 100644 --- a/contents/handbook/marketing/how-we-position-and-sell/logs.md +++ b/contents/handbook/marketing/how-we-position-and-sell/logs.md @@ -14,9 +14,7 @@ Datadog and New Relic are mature but expensive and built for infrastructure team ## The unique belief -PostHog's vision is a self-driving product: software that watches itself for bugs and conversion drops, then ships the fix while you sleep. That loop needs three things – signals, action, and the *context* that tells which signals actually matter. Most observability tools generate plenty of signals (events, errors, latency, logs) without the product context that makes them actionable. - -Logs are the backend half of the signal layer. But most observability tools treat them as text – timestamps, severity, message, search. You find the right log, then bounce to another tool to figure out who was affected, which feature flag was on, or what they were trying to do when it broke. The signal is in the data; the *meaning* is somewhere else. +PostHog's vision is a self-driving product: software that watches itself for bugs and conversion drops, then ships the fix while you sleep. That loop needs three things – signals, action, and the *context* that tells which signals actually matter. Most observability tools generate a lot of data (events, errors, latency, logs) without the product context that makes them actionable. Every PostHog log already knows the user. Click any log to jump to the user who hit it – their session replay, their plan, their journey. From there, filter on any attribute you attached at ingest. See which logs hit your top 1% of customers and which hit anonymous bots. From 976f1ed40eba0f4dbf2824973a2d3c36695c9158 Mon Sep 17 00:00:00 2001 From: SaraMiteva Date: Wed, 27 May 2026 11:46:05 +0200 Subject: [PATCH 5/6] Update logs.md --- contents/handbook/marketing/how-we-position-and-sell/logs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contents/handbook/marketing/how-we-position-and-sell/logs.md b/contents/handbook/marketing/how-we-position-and-sell/logs.md index 4bdce015c596..7fd360cf81c8 100644 --- a/contents/handbook/marketing/how-we-position-and-sell/logs.md +++ b/contents/handbook/marketing/how-we-position-and-sell/logs.md @@ -14,7 +14,7 @@ Datadog and New Relic are mature but expensive and built for infrastructure team ## The unique belief -PostHog's vision is a self-driving product: software that watches itself for bugs and conversion drops, then ships the fix while you sleep. That loop needs three things – signals, action, and the *context* that tells which signals actually matter. Most observability tools generate a lot of data (events, errors, latency, logs) without the product context that makes them actionable. +PostHog's vision is a self-driving product: software that watches itself for bugs and conversion drops, then ships the fix while you sleep. Most observability tools generate a lot of data (events, errors, latency, logs) without the product context that makes them actionable. Every PostHog log already knows the user. Click any log to jump to the user who hit it – their session replay, their plan, their journey. From there, filter on any attribute you attached at ingest. See which logs hit your top 1% of customers and which hit anonymous bots. From 033c0b360f6f6d6d5a0cc22e3b7befb365cf0e92 Mon Sep 17 00:00:00 2001 From: SaraMiteva Date: Wed, 27 May 2026 11:48:17 +0200 Subject: [PATCH 6/6] Update workflows.md --- .../handbook/marketing/how-we-position-and-sell/workflows.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contents/handbook/marketing/how-we-position-and-sell/workflows.md b/contents/handbook/marketing/how-we-position-and-sell/workflows.md index c131dfa46bd5..9c1bd8f4964d 100644 --- a/contents/handbook/marketing/how-we-position-and-sell/workflows.md +++ b/contents/handbook/marketing/how-we-position-and-sell/workflows.md @@ -26,7 +26,7 @@ Zapier and Make have triggers but can't see product data. Customer.io and Braze - **Engineer-led teams building product-led growth motions.** They want to act on product events – onboarding milestones, activation drop-offs, feature usage – without a CDP in the middle. - **B2B teams running intent-signal automation.** Triggering sales follow-ups, Slack alerts, or Linear tickets directly from product behavior, not delayed by CRM syncs. ([Croissant does this.](/customers/croissant)) - **Startups consolidating their messaging stack.** Workflows replaces Zapier + Customer.io + a CDP. -- **Customers on Customer.io, Iterable, Brevo, or ActiveCampaign for transactional and onboarding email.** Especially when most of the trigger logic already lives in product events. (Suped migrated off Customer.io.) +- **Customers on Customer.io, Iterable, Brevo, or ActiveCampaign for transactional and onboarding email.** Especially when most of the trigger logic already lives in product events. ([Suped migrated off Customer.io.](/customers/suped) - **AI-native teams building agent loops.** PostHog AI already drafts email copy from a prompt; multi-turn, agent-authored workflows ship through MCP. ### Who this isn't for