Support Hero

Last updated:

Every week, we assign one person to be the "Support Hero." If this is you this week, congratulations! Support hero is an intense but super fun week where you get to talk to a bunch of users, get the statisfaction of helping them out and contribute to a lot of different parts of our system.

All other work takes a back seat while you're doing support, so don't plan on doing any 'normal' work.


You should work your 'normal' hours during this week. Right now people in other timezones will jump in ad-hoc to catch messages that fall outside of the Support Hero's hours. Just make sure that as support hero you are doing the bulk of the debugging/fixing.

If you are planning on taking a day off or you won't be available, please find someone to swap with.


You can view the Support Hero rota in PagerDuty here.


There are a couple of channels that customer requests come in so make sure you keep an eye on all of them:

  • PostHog Users's Slack, specifically #_customer_support, where all messages will come in from the other channels
  • GitHub issues, with the main repo being the most important one
  • Sentry issues, either directly or in #sentry in our main Slack


As an engineer, when a question comes in your first instinct is to give them an answer as quickly as possible. That means we often forget pleasantries, or will ignore a question until we've found the answer. Hence the following guidelines:

  • Always respond to a question within a reasonable timeframe during your working day (<15 minutes is great, <1 hour is okay, anything over a day is too late)
    • If you're ready to look into the issue and you think it might take a while/require a fix, just mention that and say you'll get back to them
    • If you have no idea how to answer or fix their issue, @mention someone who does
  • Start your response with Hey [insert name], ... and make sure you're polite, not everyone you talk to is an engineer and as accepting of terse messages
    • If it's an email (if the source in #_customer_support is email), make sure you format your message as an email and only send a single message, not multiple
  • Follow up!
    • Papercups has an overview of Slack conversations that haven't been closed or answered yet. Occasionally have a look to see if you've missed anything

Prioritising requests

  1. Responding to and debugging issues for paying customers
  2. Responding to and debugging issues for community users
  3. Fixing issues, creating PRs
  4. Debugging Sentry errors

How to help customers

  • The reason it's so great to have engineers do support is that you can actually help customers solve their issues, rather than just escalating it. Hence you should aim to go deep and actually solve people's issues, whether that involves going deep on our functionality or spending half a day writing a PR to fix someone's issue
  • On, you can log in as a user to help debug their issues.
    • Do this by going to, finding the relevant user and clicking 'log in as them'
    • To go back to your old user, just log out
    • If they have asked for help it is safe to assume they've given permission for you to log in as them.
  • When trying to debug an issue with a customer and it's not immediately obvious, it's usually much faster to do a Zoom session. You also tend to get other useful product feedback.
  • When dealing with slowness, ask users to send a screenshot of their "System Status" page (under settings)
    • If they have a lot of volume and they're still on Postgres they should probably upgrade to Clickhouse
  • Sometimes questions will have been asked earlier in the User's Slack so it's worth searching through that if you're not sure.