/add-error-tracking

name: add-error-tracking
description: |
  Add Temps error tracking to applications using the Sentry-compatible SDK. Temps exposes a Sentry-compatible DSN that works with the official Sentry SDK for each language/framework — no code changes beyond initialization are required. Use when the user wants to: (1) Add error tracking to any app (React, Next.js, Vue, Svelte, Angular, Node.js, Python, Go, Rust, Ruby, Java, PHP, .NET, React Native, Flutter), (2) Wire up uncaught exception and unhandled promise rejection capture, (3) Configure session replay for errors, (4) Upload source maps for readable stack traces, (5) Report releases and environments, (6) Capture custom errors/messages. Triggers: "add error tracking", "add sentry", "track exceptions", "report errors", "temps error tracking", "wire up error monitoring".

Add Error Tracking

Integrate Temps error tracking (Sentry-compatible) into an application. The Temps DSN is a drop-in replacement for a Sentry DSN — use the official Sentry SDK for the user's platform and point it at the Temps DSN via an environment variable.

Prefer Sentry's official per-framework skills when available

Temps is Sentry wire-compatible, so every skill Sentry publishes for their SDKs works against a Temps DSN. If the user's CLI already has one of these installed, route them to it and only substitute the DSN:

| User's platform | Sentry skill | Source | |---|---|---| | Next.js | `/sentry-nextjs-sdk` | `getsentry/sentry-for-ai` | | React (Vite, Remix, etc.) | `/sentry-react-sdk` | `getsentry/sentry-for-ai` | | Vanilla browser JS | `/sentry-browser-sdk` | `getsentry/sentry-for-ai` | | Node.js | `/sentry-node-sdk` | `getsentry/sentry-for-ai` | | React Native | `/sentry-react-native-sdk` | `getsentry/sentry-for-ai` | | Generic (language-agnostic) | `/sentry-sdk-setup` | `getsentry/sentry-for-ai` |

For platforms Sentry has no dedicated skill for (Vue, Svelte, Angular, Python, Go, Rust, Ruby, Java, PHP, .NET, Flutter, etc.), follow the setup in this file directly.

**Always set the DSN from an environment variable — never hardcode it.** The user will point the env var at their Temps DSN instead of a Sentry DSN.

Detect the platform

Infer the platform from the codebase:

• `package.json` with `"next"` → **Next.js** → `@sentry/nextjs`
• `package.json` with `"react"` and Vite/Remix/CRA → **React** → `@sentry/react`
• `package.json` with `"vue"` or `"nuxt"` → **Vue** → `@sentry/vue`
• `package.json` with `"svelte"` or `"@sveltejs/kit"` → **Svelte** → `@sentry/sveltekit`
• `package.json` with `"@angular/core"` → **Angular** → `@sentry/angular`
• `package.json` with `"express"`, `"fastify"`, `"@nestjs/core"` → **Node.js** → `@sentry/node`
• `package.json` with `"react-native"` or `"expo"` → **React Native** → `@sentry/react-native`
• `requirements.txt`/`pyproject.toml` with Flask, Django, FastAPI → **Python** → `sentry-sdk`
• `go.mod` → **Go** → `github.com/getsentry/sentry-go`
• `Cargo.toml` → **Rust** → `sentry`
• `Gemfile` with `rails` → **Ruby** → `sentry-ruby` + `sentry-rails`
• `pom.xml`/`build.gradle` with Spring → **Java** → `sentry-spring-boot-starter-jakarta`
• `composer.json` with `laravel/framework` or `symfony/*` → **PHP** → `sentry/sentry`
• `.csproj` with `Microsoft.AspNetCore.*` → **.NET** → `Sentry.AspNetCore`
• `pubspec.yaml` with `flutter` → **Flutter** → `sentry_flutter`

Get the DSN

The user's Temps project exposes a DSN at **Error Tracking → DSN & Setup**. It looks like:

https://<public_key>@<temps-host>/<project_id>

If the user has not provided a DSN, tell them to: 1. Open their project in the Temps dashboard 2. Go to **Error Tracking → DSN & Setup** 3. Copy the DSN for the target environment

Always store the DSN in an environment variable. The exact variable name depends on the platform (browser bundlers often require a prefix to expose vars to the client):

| Platform | Env var name | |---|---| | Next.js | `NEXT_PUBLIC_SENTRY_DSN` | | Vite / React / Vue | `VITE_SENTRY_DSN` | | SvelteKit | `PUBLIC_SENTRY_DSN` | | Angular | `SENTRY_DSN` (injected via `environment.ts`) | | Everything else (Node, Python, Go, Rust, Ruby, Java, PHP, .NET, Flutter) | `SENTRY_DSN` |

# .env
SENTRY_DSN=https://<public_key>@<temps-host>/<project_id>

Browser SDKs: also pass `tunnel`

For every **browser** platform (Next.js client config, React, Vue, Svelte, vanilla JS — not server-side SDKs, not React Native/Flutter), also pass `tunnel` in the same `Sentry.init` call:

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tunnel: process.env.NEXT_PUBLIC_SENTRY_TUNNEL,
});

Why: without `tunnel`, the SDK POSTs straight to the DSN's host (the Temps console), which is a third-party, cross-origin request from the app's own domain — ad blockers commonly block it, and it costs a CORS preflight on every event. With `tunnel` set to a same-origin path, the browser posts to the app's own domain instead; Temps' proxy forwards anything under `/api/_temps` to the console regardless of which project domain it arrived on, so this works unmodified on custom domains and preview URLs.

The value is a fixed path, not a secret — Temps injects it automatically as an env var alongside the DSN, under the same bundler-specific public prefix (so if the DSN reaches the client bundle, the tunnel path does too):

| Platform | DSN env var | Tunnel env var | |---|---|---| | Next.js | `NEXT_PUBLIC_SENTRY_DSN` | `NEXT_PUBLIC_SENTRY_TUNNEL` | | Vite / React / Vue | `VITE_SENTRY_DSN` | `VITE_SENTRY_TUNNEL` | | SvelteKit | `PUBLIC_SENTRY_DSN` | `PUBLIC_SENTRY_TUNNEL` | | Angular | `SENTRY_DSN` (via `environment.ts`) | *(none — no public-prefix convention; skip `tunnel`)* |

If deploying outside Temps (or the tunnel var isn't set for some other reason), you have two options. Omit `tunnel` — the SDK falls back to posting straight to the DSN host, which still works, just cross-origin. Or point `tunnel` at the **absolute** tunnel URL of the Temps instanc