Keep your Sentry SDK and send its errors to your coding agent
Set your existing Sentry SDK's DSN to your Runheed project's Sentry SDK DSN, shaped https://<key>@runheed.com/<number>. No other code changes: exceptions, messages, stack frames, breadcrumbs, user, tags, release and environment arrive in Runheed, and your coding agent reads them over MCP.
Switch in three steps
- Create a project in Runheed (or have your agent call runheed_create_project). Copy its Sentry SDK DSN from the Projects page; runheed_list_projects shows it too.
- Replace the DSN your Sentry.init() reads, usually the SENTRY_DSN environment variable, with that value. Redeploy.
- Connect your coding agent to https://runheed.com/api/mcp and ask it for the newest unresolved errors.
import * as Sentry from '@sentry/node';
// Before: SENTRY_DSN=https://...@o123.ingest.sentry.io/456
// After: SENTRY_DSN=https://<key>@runheed.com/<number>
Sentry.init({ dsn: process.env.SENTRY_DSN, release: process.env.GIT_SHA });Which SDKs work
Every Sentry SDK sends the same envelope format, so any of them can report to Runheed. These were run end to end against Runheed on 2026-11-13:
| Language | SDK tested | Setup page |
|---|---|---|
| Node.js / TypeScript | @sentry/node 11.12 | /docs#sentry-sdk |
| Python | sentry-sdk 2.75 (gzip, chained exceptions) | /docs#sentry-sdk |
| Go | sentry-go 0.50 | /for/go |
| Ruby and Rails | sentry-ruby 7.2 | /for/ruby |
| PHP and Laravel | sentry/sentry 4.37 | /for/php |
| Java and Spring Boot | sentry-java 8.16 | /for/java |
| .NET and ASP.NET Core | Sentry 7.0 | /for/dotnet |
| Browser (React, Vue, plain JS) | @sentry/browser 11 in Chrome, cross-origin | /for/react |
Framework integrations (sentry-rails, sentry-laravel, the Spring Boot starter, Sentry.AspNetCore) build on these SDKs and send the same events.
What comes across, and what does not
| From the Sentry SDK | In Runheed |
|---|---|
| Exceptions and their chain (raise ... from, cause) | Kept: the outermost exception is the error, the rest are listed as causes |
| captureMessage / capture_message | Kept, as a Message error |
| Stack frames with source context | Kept, your own frames marked in-app, crash site first |
| Breadcrumbs, user, request, tags, extra | Kept |
| release and environment | Kept, so the agent can ask what a release introduced |
| A custom fingerprint | Used for grouping |
| Minified browser frames | Mapped to your source through the bundle's public source map |
| Transactions, spans, profiles, replays, sessions, check-ins | Accepted and dropped: Runheed tracks errors only |
Set tracesSampleRate (traces_sample_rate) to 0 so the SDK does not send performance data that would be dropped anyway.
Want Sentry and Runheed side by side?
A Sentry SDK sends to one DSN. To keep Sentry for tracing and replay and also give your agent the errors, keep Sentry's DSN as it is and add the Runheed SDK next to it (Node.js and Python), or send a copy from your own code to the Runheed ingest endpoint. The /sentry-alternative page shows the side-by-side setup.
Questions
- Do I need to change any code besides the DSN?
- No. Everything the SDK already captures keeps working. Optionally turn tracing off, since performance data is dropped.
- Do past Sentry issues move over?
- No. Runheed starts grouping from the first event it receives.
- What happens at the monthly event limit?
- Runheed answers 429 with Retry-After, which Sentry SDKs honor, so the SDK backs off instead of retrying in a loop. You are never billed for overage.