Two questions worth asking.
| Question | Sentry | Braith |
|---|---|---|
| Did the application throw an error? | Error reporting and stack traces. | Keep your error tracker for this. |
| How did the code execute? | Traces, logs and other configured diagnostic data. | Sanitised activity windows and correlated outcome events. |
| Did the customer get the intended result? | Custom instrumentation and analysis can capture relevant evidence. | AI review of recorded activity, with core outcome checks for extra context. |
| There is no completion evidence. | Depends on the instrumentation and rules you configure. | Missing telemetry alone is not treated as failure. |
| What do I add? | The SDK and the diagnostics you need. | The SDK and app context through your coding tool. Core outcome definitions are optional. |
The job finished. The download failed.
- Export requested
- Export completed
- Download failed
If no exception is thrown or captured, an exception list can remain empty. The later download failure is the evidence Braith uses to question the earlier success.
Sentry can also record custom events, logs and spans. The difference is the task model and the investigation workflow, not an inability to send a business event to Sentry.
Use the tool that answers your question.
Use Sentry when you need error diagnostics, stack traces or performance investigation. Add Braith when you need to follow important customer tasks through the result they were meant to deliver.
We use both for Braith itself. That is an internal implementation, not a claim that Braith replaces Sentry or has detected every failure.
See Sentry’s Next.js documentation for its current capabilities. Braith’s current prices and allowances are on the pricing page.