chore: rename upload source maps to upload symbols

[marandaneto]

Changes

depends on https://github.com/PostHog/posthog.com/pull/13943/files

Checklist

• [ ] Words are spelled using American English
• [ ] PostHog product names are in title case. It's "Session Replay" not "Session replay". Note: if talking about a general type of product, use sentence case e.g. "There are a lot of product analytics tools, but PostHog's Product Analytics and Web Analytics are some of the best"
• [ ] Titles are in sentence case
• [ ] Feature names are in sentence case too. It's "Click here to watch session recordings" not "... watch Session Recordings" and so on.
• [ ] Use relative URLs for internal links
• [ ] If I moved a page, I added a redirect in vercel.json
• [ ] Remove this template if you're not going to fill it out!

Article checklist

• [ ] I've added (at least) 3-5 internal links to this new article
• [ ] I've added keywords for this page to the rank tracker in Ahrefs
• [ ] I've checked the preview build of the article
• [ ] The date on the article is today's date
• [ ] I've added this to the relevant "Tutorials and guides" docs page (if applicable)

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
posthog	Ready	Preview	Dec 3, 2025 3:31pm

[edwinyjlim]

Are we sure we want to remove source maps from error tracking docs? I don't think we should. I feel like it might be too widespread and popular of a term to just ditch. Developers will scan for the words "source maps."

How do we feel about just appending and saying Upload source maps and symbols

[marandaneto]

Are we sure we want to remove source maps from error tracking docs? I don't think we should. I feel like it might be too widespread and popular of a term to just ditch. Developers will scan for the words "source maps."

How do we feel about just appending and saying Upload source maps and symbols

source maps just makes sense for web tools. for all the other symbol types, not really. imo source maps and symbols is ambiguous since source maps is a symbol type. i do understand your concern tho, so not sure whats the best here.

calling upload source maps for android mappings makes no sense calling source maps for ios debug symbols either.

[edwinyjlim]

source maps just makes sense for web tools.

Yeah, I totally hear you on what the actual relationships are

But for discoverability purposes,Source maps and symbol sets or something like that probably has us covered? I'd rather be verbose if it helps people find what they need

[daibhin]

Totally agree that mentioning symbol sets is important but makes us look like we don't know what we're talking about when we use it in the context of Android / iOS.

Right now the nav bar looks like:

Start here
Installation >
Upload symbol sets >

Would it make sense to reorganise like:

Start here
iOS >
  Installation
  Upload debug symbols
NextJS >
  Installation
  Upload symbol sets
Ruby
Python
...

Some platforms don't even require symbols (e.g. Ruby, Python) so wouldn't even need to be a dropdown. Feels intuitive that the platforms live at the root because that's what most people are looking for anyways.

My only concern is that there is a growing number of platforms so that list might get long and push the other sections too far down

[edwinyjlim]

let's split by term when appropriate then?

Start here
Installation >
Upload source maps >
Upload symbol sets >
Upload debug symbols >
...

Bringing languages and platforms to the top-level nav is the only thing I'm strongly against 😅

[daibhin]

Hahaha ok, won't push for root level languages.

Don't want to bikeshed this too much but having categories for each feels really confusing to me e.g. what do I care / know about debug symbols if I have a NextJS app

We should probably change the nav bar item to be the generic term "symbol sets" in that case but leave the routes as "source-maps" and "debug-symbols" respectively

Start here
Installation >
Upload symbol sets >
...

[edwinyjlim]

Don't want to bikeshed this too much

it's all I do 🤪

yea i'm happy to go with symbols or symbol sets if the team is unified here. I'm just adding my voice from my pov

[hpouillot]

We are using the term "unresolved" frame in stack trace components so maybe we could have something like this:

Start here
Installation >
	Javascript > 
		Express
		Hono
		React
		Angular
		NextJs
		Nuxt
		Svelte
	Python >
		Django
		Flask
	Kotlin >
		Android
	Flutter
Resolution >
	Overview
	Javascript >
		NextJs >
		Vite > 
		Rollup >
		Webpack >
		CLI > 
	Android >
		Gradle ? 
...

I like having two entrypoints, one for installation and one for resolution. We are adding bundler plugin and framework integration so users could use posthog-js and @posthog/rollup-plugin. Wdyt ?

[edwinyjlim]

@hpouillot I think two entry points makes sense.

Putting aside the symbol types and formats, what is the ultimate goal? Are all of these formats and options in pursuit of resolved stack traces?

Start here
Installation >
Resolve stack traces >
   ...[Hugues's suggested format]

[hpouillot]

Uploading symbol set also improves grouping but for the user, the ultimate goal is to see the source code associated to an error, so Resolve stack traces would work for all languages I think.