posthog New product: Error tracking

The Replay team are working on a new Error tracking product within PostHog. In helping customers to build more successful products one of the most common requests we get is whether I can watch sessions of users who've encountered errors.

A big part of the reason people request this is that they want to identify and resolve the most important issues their customers face, whether that be because it occurs frequently, affects a VIP customer or happened during the checkout flow. Network response status and speed, Errors, Events, and Replay overlap to give a full picture of what's happening in the user's app.

Given PostHog already captures so much context about user sessions it makes total sense to integrate an exception tracking product that can compliment our existing user filtering and session replay.

Our first version will include:

SDK support to capture errors in one front-end and one back-end language (almost certainly JS and Python). Including autocapture
Stack traces are actionable and human-readable (un-minifying / source map uploading)
Grouping of similar exceptions and errors
High-volume or high-value errors trigger the Alerting system
Advanced user filtering
Integrated with other products and features including as Session replay, Product analytics and Discussions

The Replay Team is actively working on this and we'd love to hear user feedback, as well as ideas for features or stretch goals. Please add to this issue!

If you like this idea, please leave a 👍 or ❤️ reaction on this post to vote for it -- we're actively recruiting beta testers and will reach out to give you early access!

Jul 02 '24 14:07 daibhin

Would love to have it on mobile! Would be able to drop Crashlytics from my apps and go full PostHog!

Oct 17 '24 09:10 VladislavSmolyanoy

@VladislavSmolyanoy we're not quite ready to support mobile just yet but it's certainly on our list of platforms to explore in the future.

~Since posting we've moved to a closed beta with interested customers for our JS and Python SDKs. If you would like access please reach out to me via email (first name @ posthog.com)~ Error tracking is now in early access beta! You can enable it in the feature previews panel in the PostHog app.

Dec 09 '24 09:12 daibhin

Another request (Mobile) https://x.com/gsharm1/status/1865155991458713823

Dec 09 '24 10:12 marandaneto

gods of posthog please bless us with crashlytics alternative on mobile

Dec 09 '24 10:12 VladislavSmolyanoy

Another request for mobile support: https://posthog.com/questions/react-native-expo-support-for-error-tracking

Jan 31 '25 17:01 daibhin

Another request for mobile (Flutter this time): https://posthog.com/questions/flutter-error-tracking

Feb 03 '25 11:02 daibhin

I"ve posted this 2 places ...

https://posthog.com/questions/react-native-expo-support-for-error-tracking
https://posthog.com/wip

...and am adding it here for good measure...

Hi @daibhin & Co! I've worked with both LogRocket & Sentry for error tracking and session replay with React Native / Expo. In my experience, tracking the JS / React errors was integral to setting up session replay -- like these 2 technologies were coupled.

For the native side of React Native, I understand that is more difficult to build. It took LogRocket many years to get there and delayed Sentry's support for React Native for a while in their session replay.

All to say, I am surprised that you don't support error tracking out of the box for the JS / React layer in React / Expo. LogRocket had this for many years and Sentry eventually launched with it in their session replay for RN.

Unlike Flutter or the native apps, you already have a solution for the JS / React tree. Is it possible you can adapt this a bit further for React Native before you support the native layer ?

Cheers!

Mar 12 '25 20:03 smlarkin

Hey @smlarkin,

Thanks for reaching out and providing such context.

I totally agree with your point that supporting the JS layer in React Native should not be blocked by the more complicated native mobile support (that will take us some time to get to).

One thing you can do today is call posthog.captureException form the RN SDK but it is nowhere near full support. Being honest we debated even including that option for exactly this reason - we didn't want to confuse customers as to whether we supported React Native or not given the answer is that we don't officially.

All that being said, it should be possible with relative little lift to add more support for React Native. We are working towards a more general release in the next couple of weeks. It has always been our intention to only support Python and Web / Node JS at launch. We still want to make sure that goes according to plan and we don't half support every language / framework. I will make a note to fast follow with better React Native support once we've launched.

Mar 14 '25 09:03 daibhin

Hey @smlarkin,

Thanks for reaching out and providing such context.

I totally agree with your point that supporting the JS layer in React Native should not be blocked by the more complicated native mobile support (that will take us some time to get to).

One thing you can do today is call posthog.captureException form the RN SDK but it is nowhere near full support. Being honest we debated even including that option for exactly this reason - we didn't want to confuse customers as to whether we supported React Native or not given the answer is that we don't officially.

All that being said, it should be possible with relative little lift to add more support for React Native. We are working towards a more general release in the next couple of weeks. It has always been our intention to only support Python and Web / Node JS at launch. We still want to make sure that goes according to plan and we don't half support every language / framework. I will make a note to fast follow with better React Native support once we've launched.

Thanks for your reply, @daibhin !

I can imagine the biggest efforts are JS, PY, vanilla React.

For some context, an awful lot of React Native developers only need the JS/React errors tracked and surfaced in a session replay. Anything lower, can be bucketed as "native error" or something like that. That's how LogRocket worked for 2 years I used it and it was still invaluable to my company. Sentry has taken this to a whole other level with native support and error emails with session prieviews, but 99% of the time we just need to know what broke in JS/React world.

If you need any beta testing or help for React Native, I would be happy to lend a hand :)

Mar 14 '25 15:03 smlarkin

Any docs on how to upload the source maps manually from CI so we don't have to include them in our production deploys?

Mar 15 '25 00:03 kdawgwilk

Hey @kdawgwilk! We just launched a CLI to make this possible: https://posthog.com/docs/error-tracking/stack-traces#uploading-source-maps. Let me know if you run into any issues setting that up :)

Mar 20 '25 10:03 daibhin

@daibhin How do I authenticate the CLI in CI like GitHub actions?

Mar 20 '25 18:03 kdawgwilk

@kdawgwilk you can set POSTHOG_CLI_TOKEN and POSTHOG_CLI_ENV_ID environment variables as an alternative to the login command steps. Thanks for the heads up that wasn't actually documented anywhere 😅 Added in https://github.com/PostHog/posthog.com/pull/11032

Mar 21 '25 14:03 daibhin

I downloaded the CLI and attempted to upload the sourcemap generated by Expo using step 3 for web but am getting the following error: Oops! Failed to parse sourcemap: encountered incompatible sourcemap format.

What format is this expecting?

Mar 28 '25 21:03 jtstodola

Hey @jtstodola, it's expecting a standard .js.map file similar to the one you get when visiting https://app-static-prod.posthog.com/static/chunk-C6TQ5FFZ.js.map

For context, we use this package to parse sourcemaps and the error you're seeing is coming from https://github.com/PostHog/posthog/blob/191e2b1af34e1271f509b79120c29410a33dbf9b/cli/src/utils/sourcemaps.rs#L103

I don't see any reason it shouldn't work but I'll be honest in saying I am not an Expo expert. I see that you just opened a support ticket. Let's work through things there and I can loop back publicly if this turns out to be something more generally useful

Mar 31 '25 17:03 daibhin

@daibhin I am getting the following error when trying to upload the same source maps to another posthog project. The first project succeeds perfectly. I have multiple projects and I thought I would need to upload the source maps to each project individually but are these shared across all projects in an org?

2025-04-01T22:41:27.059598Z ERROR posthog_cli: msg="Oops! Chunk ID already set"

Apr 01 '25 22:04 kdawgwilk

@dyj0183 @kdawgwilk I'm keen for this thread not to get too off topic. It would be great if you could both open new issues with the problems you're facing, or an in-app support ticket if you can

Apr 02 '25 08:04 daibhin

Just to add up to the pressure. Please, bring Mobile support when you have time! An All-in-one solution would be awesome for us (iOS in my case) 🙏🏼

Apr 10 '25 10:04 JuanColilla

+1 for native iOS support!

Apr 12 '25 11:04 paulofaria

For anyone who missed the news - Error tracking has now launched 🎉

I'm conscious a lot of the chatter in here was about support for mobile platforms so I have pulled that into a feature request of its own: https://github.com/PostHog/posthog/issues/31117. It's not something we're working on right away but is certainly on our radar as a future improvement.

For any other issues / feedback related to error tracking please open separate issues or message the team in-app.

Apr 14 '25 07:04 daibhin