Email comms

Last updated:

|Edit this page

We regularly send two emails.

  1. Changelog, a product announcement email sent every month. Sent via
  2. PostHog for Startups, an email to users of our startup program. Sent monthly, via

In addition, comms also owns the onboarding email flow, which is controlled by


The changelog email is part of the new release process and is used for product announcements.

Every month, we use to share a broadcast which summarizes the highlights from the weekly changelog over the last month. We use our discretion to choose which updates to highlight, usually showcasing three or four of the most impactful changes. We usually reserve the top spot for making users aware of new beta features. A test is shared with the team ahead before we send to users.

The changelog email always ends by directing users to subscribe to Product for Engineers.

We tag these emails as Product updates in, so users can manage their subscriptions.

PostHog for Startups

Each month, we send an email to users in our PostHog for Startup program. This email goes to all users in any org which is registered in the program, and the list of users (and their org_ids) are tracked in the mailing list sheet. A test is shared with the team ahead before we send to users.

Each month, Joe combines new orgs into the startups cohort and exports this to for this email.

The email is usually comprised of three sections, which inform users of new guides which are relevant to startup use-cases, new betas which are available for them to try, and a spotlight written of a new org in the program. We end by asking for feedback.

We categorize these emails as Actually useful marketing emails in, so users can unsubscribe if they wish.

Onboarding emails

The onboarding email logic is complex, and regularly changes as we test new ideas. Any changes to it are, as with all other email campaigns, documented in the Meta repo. The latest revision is Onboarding 5.1.

The onboarding flow is composed of several workflows, with dedicated flows for:

  • All cloud sign-ups
  • All self-hosted sign-ups
  • All open-source deploys
  • Cloud users who have not subscribed to replays
  • Cloud users who have not subscribed to feature flags

We aim for all content in these flows to be relevant and helpful to users, without being salesy. We use a mix of personal and 'designed' email styles, with personal emails coming directly from the inbox of relevant people (namely, Andy and Joe). When we get replies or feedback to these emails, we share it on Slack.

A full description of the flows above is found in the Onboarding 3.0 issue.

We tag all these email flows as onboarding in and categorize them as Welcome emails so that users can easily manage their preferences.

Other email communications

Any ad-hoc customer communications over email are owned by the comms team, and are usually sent via These can include product updates, outage alerts, or other PostHog news if needed.

These emails are usually tagged as Service updates in when they include important account or product information. These emails are given a dedicated unsubscribe option in the footer, making it clear that we do not recommend users unsubscribe to these emails.

Important service updates are the only type of email we may send to unsubscribed users, and only if we feel it is warranted to do so.

Service updates emails are usually part of an engineering incident. If an incident is declared, please ensure the comms team is aware as soon as possible by posting in the #team-comms Slack.

We are currently testing email as a channel for other activities, such as product upsells. We tag these emails as Actually useful marketing emails in and have found the a personal, non-designed approach works best.

Whenever we plan a new email activity we open an issue in the Meta repo using the Messaging issue template. This enables us to summarize information and seek approval from teams while also keeping our work open source, and without requiring everyone log in to Issues are closed when an email is completed.

If you'd like to work with comms on an email activity, please begin by opening an issue in the meta repo


Was this page useful?

Next article

In-app comms

Occasionally, we use in-app messages to tell users about certain things. We recognize that in-app messages can be intrusive and we want to avoid spamming our users with too many of them, too frequently. For that reason, we're judicious about the way in which we use them. We currently don't have a separate system for tracking in-app messages, so Comms currently owns the channel and is responsible for ensuring that messages aren't used excessively. Types of in-app message Currently, there are…

Read next article