Most teams already have Sentry running. It catches errors, groups them into issues, and sends someone an alert. The problem is what happens after the alert. Someone opens Sentry, reads the stack trace, SSHes into a server, pulls logs, and spends 30 minutes figuring out what actually caused the failure. The error is just the starting point. The investigation is where the time goes.
BitSentry’s Sentry integration closes that gap. Instead of stopping at “here’s an error,” it pulls the error data into an automated investigation pipeline.
What the integration does
When you connect your Sentry organization to BitSentry, the platform starts pulling two things:
Issues are Sentry’s grouped errors. Each issue represents a class of error that’s happened one or more times. BitSentry ingests the issue title, severity level, status, and timestamps (first seen, last seen). This gives the system context about what’s been going wrong and for how long.
Events are individual error occurrences within an issue. Each event includes the full stack trace, timestamp, log level, and message. BitSentry uses these as the raw signal for root cause analysis.
The sync runs automatically on a configurable interval (10 minutes by default). You can also trigger a manual sync if you want fresh data immediately.
How it connects
The integration uses Sentry’s REST API (v0). You provide a bearer token, and BitSentry connects to your organization. From there, it discovers your projects and starts pulling issues and events.
A few things that matter for production use:
Sentry rate-limits API requests. BitSentry respects 429 responses and backs off automatically using the Retry-After header. If that header is missing, it uses exponential backoff with up to 5 retries.
Sentry paginates results with cursors. BitSentry follows pagination links to pull complete datasets.
Treat the Sentry API token like any production credential: scope it narrowly, rotate it when needed, and only grant read access to the org/projects you want investigated. BitSentry resolves the token at runtime when making Sentry API calls.
What happens after ingestion
Once BitSentry has your Sentry data, it becomes part of the investigation pipeline. When a diagnosis starts, the Sentry errors provide context:
- Which services are throwing errors
- When the errors started
- Whether the error rate is increasing
- What the stack traces point to
The AI uses this alongside SSH log data to correlate errors with system state. Instead of reading a Sentry issue and then separately SSHing around to find the cause, you get both connected.
Filtering what gets pulled
You can filter the sync by project. If you have 20 projects in Sentry but only care about 3 for incident diagnosis, you configure those 3. BitSentry also supports log-level thresholds: you can tell it to only pull errors and warnings, skipping info and debug events.
Setting it up
- Create a Sentry API token with read access to your organization
- Add the token in BitSentry’s integration settings
- Select which projects to sync
- Set the sync interval (or keep the 10-minute default)
First sync takes a few minutes depending on how many issues you have. After that, it’s incremental.
Why this matters for on-call
The on-call engineer’s job isn’t to look at errors. It’s to find what caused the error and fix it. Sentry does a great job of surfacing errors. BitSentry takes those errors and runs them through an investigation that would normally take 30-45 minutes of manual work.
If your team already uses Sentry and you’re tired of the gap between “error alert fired” and “root cause found,” this integration is the bridge.