Skip to content
Knowledge base

Use your existing Sentry SDK

Already have Sentry's SDK installed? Point its DSN at realuptime and keep it: no SDK swap, no re-instrumentation.

1. Why this exists

Sentry's SDKs (JavaScript, Python, and the rest of the ~100 official and community integrations) are already wired into most apps that have error tracking at all. Rather than asking you to rip that out, realuptime accepts the Sentry SDK protocol directly: the same init(dsn) call, the same envelope format, the same auth. Your code does not change.

2. Find your project's realuptime-flavored DSN

Open a project in realuptime Errors settings. Alongside the native ingest key, a "Point any Sentry SDK here" panel shows a DSN in Sentry's own shape: https://<key>@realuptime.io/<key>. Copy it whole.

3. Paste it into Sentry.init

Wherever your app currently calls Sentry.init({ dsn: "https://...@o0.ingest.sentry.io/0" }), swap in the realuptime DSN. Nothing else in the call changes: SDK version, integrations, beforeSend, and sample rates all keep working exactly as configured.

4. What arrives on your dashboard

Exceptions, messages, breadcrumbs, tags, release, environment, user context, and runtime info all translate into the same issue model your realuptime SDK would produce, so the SAME error reported through Sentry's SDK or ours groups into one issue, not two. Grouping, your project's scrub rules, ingest ceilings, and quota all apply identically -- translation happens once, at the edge, before anything is stored.

5. What does not translate

realuptime Errors does not ship a tracing/APM product, so Sentry's performance `transaction` envelope items are accepted and discarded (not stored, not billed, not an error). Attachments (screenshots, minidumps) are rejected with a clear response rather than silently dropped, since we do not store binary attachments today.

6. Rate limits and quota behave the same way

The Sentry-shaped endpoints share the exact ingest rate limiter and monthly quota your native ingest key uses. Over the limit, the response is a standard 429 with a Retry-After header, which every Sentry SDK already backs off on -- no custom handling needed on your end.

Go deeper

The full reference lives in the docs: Getting started documentation. Error codes named above are each explained in the error-code reference.