Create one Sentry project per runtime. The "platform" you pick during project creation only affects defaults (suggested integrations, onboarding text), it does not change what the SDK can send. Pick the closest match.

If seed-site, seed-notify, or seed-electron already exist with a different platform value (e.g. "Browser" or "Node"), don't recreate, the platform is mostly cosmetic. Just verify the slug matches what the code sends to (vite.config.mts, vite.main.config.mts, etc. all hard-code these slugs).

No separate project for the Go daemon. Native (Electron + Go) crashes route through seed-electron because that's where the Electron main process is initialised and where sentry-cli debug-files upload pushes daemon symbols. If we ever ship a standalone server-side Go service that should report independently, create a seed-daemon project with platform Go at that point.

How to create a project

Our CI uploads sourcemaps and creates releases via sentry-cli and @sentry/vite-plugin. Both require SENTRY_AUTH_TOKEN.

Settings → Account → User Auth Tokens → Create New Token

Scopes (minimum):

project:read

project:releases

org:read

project:write (only if you want CI to be able to mutate project settings, usually skip)

Name: ci-mintter-seed (or similar so it's identifiable later).

Copy the value once, it's not shown again.

Save the token to GitHub repo secrets as SENTRY_AUTH_TOKEN (likely already done; verify under Settings → Secrets and variables → Actions).

Rotate every 6 months. Old tokens stop working silently, releases keep getting created locally but sourcemaps fail to upload. Add a calendar reminder.

---

Without this, our CI runs sentry-cli releases set-commits --auto but Sentry has no way to map commit SHAs back to authors/files, so Suspect Commits stays empty.

Settings → Integrations → GitHub → Install

Authorise the GitHub app on the mintterteam/mintter (or repo owner) org.

After install, go to Settings → Integrations → GitHub → Configure and tick the repository (seed / mintter or whatever the repo is currently called).

In each project (seed-site, seed-notify, seed-electron): Settings → Projects → <project> → Source Maps & Repositories → Add Repository → GitHub → <repo>.

After this is set, push a commit and watch the next release: Releases → <release> → Commits should show the commit list and Suspected Commit should appear on issues.

---

Each project needs explicit environments so we can filter and alert per env.

In each project: Settings → Projects → <project> → Environments

Create:

Mark development as "Hidden" if you want to ignore local-dev noise.

Set retention rules per env if you want shorter history for dev.

---

Crash-free sessions / users only work if Release Health is on.

For each project: Settings → Projects → <project> → Releases → Release Health → enable.

Specifically required for seed-electron if you want crash-rate-per-release alerts (a common one for desktop apps).

For Remix projects it's still useful but lower-priority.

---

Bare-minimum alert set per project. Create under Alerts → Create Alert.

seed-electron

Issue alert: new issue affecting > 25 users in 1 hour, in env production → email/Slack the team.

Metric alert (Crash-Free Session Rate): crash-free-session-rate < 99% for 5m on env production → page on-call.

Issue alert: any new fatal-level issue in env production → page immediately.

seed-site / seed-notify

Per project: Settings → Projects → <project> → Inbound Filters

Toggle on:

✅ Browser Extensions (huge noise source for seed-site and seed-electron renderer)

✅ Web crawlers (for seed-site)

✅ Localhost (skip on seed-electron, since the renderer reports localhost URLs in normal use)

✅ Filter out errors known to be caused by old browsers (for seed-site)

You can also add custom URL filters, e.g. to ignore errors from preview/staging hostnames.

---

Settings → Security & Privacy → Data Scrubbing (org-level) and also per-project.

✅ Keep "Use default scrubbers" on (passwords, credit cards, SSNs, common token patterns).

Add custom scrubber fields if you have known sensitive cookie/header names. At minimum:

Authorization (header)

any cookie names used for auth in the web app

dsn, apiKey (if either ever ends up in extras)

✅ "Prevent storing of IP addresses", leave off only if you actually need GeoIP per event. Our SDKs send sendDefaultPii: false, so IPs already aren't sent.

---

Profiling + replays + tracing-at-100% can spike costs surprisingly fast. Set caps now.

Settings → Subscription → Spend Allocation

Set a monthly cap on:

Transactions (tracing), start low, watch a week, raise.

Profiles, usually correlated with transactions; cap at the same ratio.

Replays, replay-on-error is 100% sample, so spikes during incidents.

Attachments, only matters if minidumps get large.

Recommended starting allocation (rough; tune after week 1):

seed-electron: 50% of transaction budget, 80% of profile budget, 60% of replay budget.

seed-site: 40% / 15% / 30%.

seed-notify: 10% / 5% / 10%.

---

Settings → Performance → Dynamic Sampling

Turn this on per project. It applies a server-side throttle on top of our in-app tracesSampler, prioritising:

Slow transactions

Transactions with errors

Rare endpoints (preserves coverage on the long tail)

Without it, our 0.1–0.2 client sample rates can produce a flat distribution; with it, you keep the interesting events at the same volume.

---

After the first production deploy with the new setup, confirm the pipeline actually works:

Source maps (web + electron renderer/main/preload)

Releases → <release sha or version>, should list "Artifacts" with files like app/entry.client-XXX.js and matching .map.

Open any issue in seed-site or seed-electron. Click View Source on a frame. You should see original TypeScript. If you see minified JS, the release name in the SDK init doesn't match the release name in the upload.

If broken: check that release in the SDK init equals release.name in sentryVitePlugin. They both come from the same env var (SITE_SENTRY_RELEASE for web → commit SHA; VITE_VERSION for desktop → git tag). Confirm both are set in the failing CI run's logs.

Native daemon symbols (electron only)

Settings → Projects → <project> → Replays

✅ Confirm replay capture is enabled.

Set "Block media" + "Mask all text" defaults (we already pass these in code; this is a belt-and-suspenders).

Privacy: confirm sampling won't capture PII inputs, our replayIntegration({ maskAllText: true, blockAllMedia: true }) covers the common cases, but verify by watching one captured replay.

---

Insights → Web Vitals, this auto-populates with browserTracingIntegration from v8. After 24h of prod traffic, you should see LCP/FCP/CLS/INP per route. No config needed; just confirm it's filling.

If empty after a day:

Check that the SDK is initialised (open prod site → DevTools → Network → filter for ingest.sentry.io → should see /envelope/ POSTs).

Check that you're not in dev env, Web Vitals filter defaults to production.

---

Settings → Projects → <project> → Ownership Rules

Map paths to GitHub teams so issues auto-assign:

Combined with the GitHub integration, this means a new issue from entry.client.tsx auto-assigns to the web team without anyone routing it manually.

---

Run through this once after deploying with the new setup:

[ ] All three projects exist with correct slugs.

[ ] SENTRY_AUTH_TOKEN set in GitHub Actions secrets, valid scopes.

[ ] GitHub integration installed and repo linked to all three projects.

[ ] Environments production and dev exist per project.

[ ] First release after merge appears under Releases with commits attached.

[ ] Open any issue → View Source shows original TypeScript.

[ ] Settings → Debug Files for seed-electron lists Go binaries with build IDs.

[ ] Inbound filters: browser extensions enabled.

[ ] Spend caps set for all three projects.

[ ] Dynamic Sampling enabled per project.

[ ] At least the "new issue affecting > N users" alert exists per project, routed to Slack.

[ ] Replay quota covers expected daily volume.

[ ] (Web only) After 24h of traffic, Insights → Web Vitals populated.

---

So you know what to change in code if a Sentry-side change requires a code change:

---

If a setting in this doc is missing in the dashboard but the code expects it, errors will silently drop or events will appear unsymbolicated. Run through section 15 once and you're done.