Error Tracking

Temps includes Sentry-compatible error tracking built-in — point your existing @sentry/react, @sentry/nextjs, or any other Sentry SDK at your Temps DSN and errors appear in your dashboard with zero code changes. No Sentry account, no monthly bill, no data leaving your infrastructure.

How it works

Temps implements the Sentry envelope ingestion protocol at /api/<project_id>/envelope/, so any Sentry SDK works without modification. Error grouping uses a built-in vector similarity engine — no OpenAI API call is made; embeddings are computed locally using a hash tokenizer into a 384-dimension vector, then stored in pgvector for cosine-similarity lookup. The platform captures the full Sentry feature set — envelope protocol (v7+), stack trace fingerprinting, source map parsing, user and request context, breadcrumbs, session correlation, and W3C trace ID correlation with spans and proxy logs — all running on your own infrastructure with no third-party services, no per-event pricing, and full integration with Temps analytics and session replay.

Sentry compatibility

Temps implements the complete Sentry envelope protocol, allowing you to use official Sentry SDKs without modification.

Supported Features

Compatibility Matrix

Setup and integration

Get started with error tracking in minutes using your existing Sentry SDK.

Step 1: Get Your DSN

Each project gets a unique DSN (Data Source Name) for error reporting. The DSN format is:

https://<public_key>@<temps_app>/<project_id>

Example DSN format:

https://0000000000000000000000000000000000000000000000000000000000000000@your-temps-instance.com/1

Step 2: Install Sentry SDK

Install the official Sentry SDK for your platform:

npm install @sentry/react

Step 3: Configure SDK

Point the Sentry SDK to your Temps instance:

import * as Sentry from '@sentry/react';

Sentry.init({
  // Copy your DSN from: https://<temps_app>/projects/<project_slug>/errors?tab=setup
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN || 'YOUR_DSN_HERE',
  environment: 'production',
  release: '[email protected]',

  // Performance monitoring
  tracesSampleRate: 1.0,

  integrations: [new Sentry.BrowserTracing()],

  beforeSend(event, hint) {
    // Filter sensitive data
    return event;
  }
});

Step 4: Test Error Tracking

Trigger a test error to verify setup:

// Throw test error
Sentry.captureException(new Error('Test error from Temps'));

// Capture message
Sentry.captureMessage('Test message', 'info');

// Add breadcrumb
Sentry.addBreadcrumb({
  message: 'User clicked button',
  level: 'info',
  data: { button: 'signup' }
});

Error grouping

Temps automatically groups similar errors together using stack trace fingerprinting and local vector similarity clustering.

Grouping Strategies

Custom Fingerprinting

Override default grouping with custom fingerprints:

Sentry.captureException(error, {
  fingerprint: ['database-error', 'connection-timeout'],
});

// Dynamic fingerprint
Sentry.captureException(error, {
  fingerprint: ['api-error', error.response?.status],
});

Update Group Status

Merge and split operations are available in the dashboard via the Error Details page Actions menu. Use the CLI to update group status:

# Resolve a group
bunx @temps-sdk/cli errors update --group-id <group-id> --project-id <project-id> --status resolved

# Ignore a group
bunx @temps-sdk/cli errors update --group-id <group-id> --project-id <project-id> --status ignored

Error details

Each error event captures comprehensive context for debugging.

Error Anatomy

Enrich Error Context

Add custom context to errors:

Sentry.setUser({
  id: 'user-123',
  email: '[email protected]',
  username: 'johndoe',
  subscription: 'pro'
});

Source context

Temps can show the actual source code around each stack frame, not just file:line. How the source gets there depends on the language.

JavaScript / TypeScript resolves automatically from source maps — the original source travels inside the .map (sourcesContent), so minified production frames turn into readable code. The official Sentry build plugins and sentry-cli upload to Temps unchanged; for git-based deploys Temps injects SENTRY_URL / SENTRY_AUTH_TOKEN, so uploads are zero-config.

Go, Rust, Python, and other compiled or native languages already report the original file:line — they just don't ship the source. Upload the raw source per release and Temps renders the code around each frame.

Keeping releases in sync

The release you upload source under must match the release your app reports (SENTRY_RELEASE) — typically the deployed commit SHA or tag. Temps injects SENTRY_RELEASE at deploy time (the commit SHA for git builds, the image tag or digest for image deploys), so keying your uploads the same way makes them line up automatically.

Uploading source

For git-based deploys, enabling the toggle is all you need — Temps captures the source from the build automatically, keyed by the commit SHA.

For image deploys or custom CI, upload it yourself, keyed by the same release:

# Upload every source file under the repo, keyed by the release.
bunx @temps-sdk/cli errors source-files upload \
  --project-id <id> --release "$CI_COMMIT_SHA" --dir .

Trace Correlation

Temps stores a W3C Trace Context trace ID alongside errors so the unified Observe page can link an exception to the request, spans, and other events that share the same trace. This is what powers the cross-source jumps in the /projects/<slug>/observe timeline.

Schema

The m20260502_000001_add_observe_correlation migration (shipped in temps 0.1.0) adds the correlation columns and lookup indexes. Every column is nullable, so existing rows are unaffected, and the migration is written to be safely re-runnable — each step uses IF NOT EXISTS.

Supporting indexes added by the same migration:

How the trace ID is extracted

For error events, temps-error-tracking ingestion probes the event payload for a trace ID and promotes the first valid value to error_events.trace_id_indexed. It checks, in order: data.sentry.contexts.trace.trace_id, top-level data.contexts.trace.trace_id, and data.trace.trace_id. A value is accepted only if it is exactly 32 ASCII-hex characters and is not the all-zero trace ID the W3C spec reserves as invalid.

The temps-proxy reverse proxy includes a helper, extract_traceparent_trace_id, that reads the inbound traceparent request header (matched case-insensitively against traceparent, Traceparent, and TRACEPARENT), splits on -, and takes the trace-id field. It applies the same validation: the value must be 32 ASCII-hex characters, must not be all zeros, and is lowercased before use. Six unit tests cover the valid case, a missing header, the all-zero value, the wrong length, non-hex characters, and uppercase folding.

To send a trace ID through to Temps, set a standard traceparent header on the request:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
              │  └─ trace-id (32 hex) ────────────┘  └─ span-id ──┘  └ flags
              └─ version

Error resolution

Manage error lifecycle from discovery to resolution.

Error States

Mark as Resolved

# Resolve error group
bunx @temps-sdk/cli errors update --group-id <group-id> --project-id <project-id> --status resolved

# Resolve multiple groups (run per group)
bunx @temps-sdk/cli errors update --group-id error-123 --project-id <project-id> --status resolved
bunx @temps-sdk/cli errors update --group-id error-456 --project-id <project-id> --status resolved

Ignore Errors

Suppress known errors you don't want to track:

Sentry.init({
  dsn: '...',
  ignoreErrors: [
    // Ignore specific error messages
    'ResizeObserver loop limit exceeded',
    'Non-Error promise rejection',

    // Ignore error patterns
    /^Loading chunk [\d]+ failed$/,
  ],

  // Ignore errors from specific URLs
  denyUrls: [
    /extensions\//i,
    /^chrome:\/\//i,
  ],

  beforeSend(event, hint) {
    // Custom ignore logic
    if (event.exception) {
      const error = hint.originalException;
      if (error.message?.includes('Network error')) {
        return null; // Don't send to Temps
      }
    }
    return event;
  }
});

Additional Resources