Core checks
- Event ingest
- Issue triage
- Release flow
- Alerts and monitors
Migrate and evaluate
Compatibility means the route works.
urgentry stays compatibility-first on the common Sentry ingest and triage path. Read the boundary, then run the route you care about.
SDKs stayExisting Sentry SDKs remain the starting point.
DSN swapThe migration story is centered on changing the host, not rewriting the app.
Validation firstProve the route with your own workflows before widening the rollout.
Public claimThe compatibility line stays explicit instead of vague.
What to validate
Test the route with the workflows your team already knows.
Deeper product checks
- Discover and logs
- Replay and profiles on the paths your team already uses
- Operator routes that matter to the rollout
Trust receipt
Who maintains the compatibility claim and where to verify it
This page defines the narrow public compatibility claim. Use these receipts to verify the scope, the maintainers, and the supporting matrices.
Page facts
- Last updated: April 17, 2026
- Maintained by: Wraxle LLC and the public repo maintainer lane
- Support: /docs/support/
- Security: /security/
Claim scope
The compatibility claim covers the common Sentry ingest and triage path. It does not claim full Sentry parity on day one.
Scope now
Keep the scope explicit.
The live compatibility matrix stays in the repo because the claim changes as the code changes. Use this page for the short version, then read the matrix before you move traffic.
In scope now
- DSN and project-key auth
- Legacy store and envelope ingest
- Issue triage, releases, environments, and alerts
- The common query path teams use in the first switch test
Not claimed yet
- Full Sentry parity on day one
- Enterprise governance as the first buying reason
- Deep native or mobile workflows as the first requirement
- A broad observability-first replacement story
Read the supporting pages together.
Use the migration guide for the DSN change path, the benchmarks page for the public performance line, and the support page if the proof fails.
Compatibility matrix
Match the route family to the check you should run.
| Route family | Current public posture | How to verify it | Where to read more |
|---|---|---|---|
| Envelope ingest and store | Compatibility-first on the common ingest path | Swap the DSN in one existing SDK and confirm one real event lands | Getting Started |
| Issue triage and project reads | Core workflow should feel boring, not novel | Load the issue list, inspect one issue, and check releases or alerts on a real project | Features |
| Alerts, monitors, and release-adjacent flows | Validate the workflows your team already depends on before cutover | Trip one issue alert, one metric or monitor path, and one release-aware workflow | Alerts and Monitors |
| Discover, logs, replay, and profiles | Supported as product surfaces, but still test the paths you actually use | Run one real query and follow it into the replay, trace, or profile path your team cares about | Discover and Logs |
Receipt example
Keep the first proof short and reproducible.
curl -X POST http://localhost:8080/api/default-project/store/ \
-H "Content-Type: application/json" \
-H "X-Sentry-Auth: Sentry sentry_key=<public_key>,sentry_version=7" \
-d '{"event_id":"compat-proof-1","message":"compatibility proof"}'
Expected receipt
- The request returns cleanly
- The event shows up in the UI and groups sanely
- The follow-up workflow you care about still behaves the way your team expects
Run the proof, then come back here when you need detail.
Start with the migration proof. Use SDK setup and benchmark details only when they change the decision.