Compared
MLReps and Sentry
We have Sentry. Isn't that already the picture of how our software behaves? Very little, honestly. One watches software that is running; the other reads software that is written. The overlap is the question they are both asked — “why is this slow” — and they answer it from opposite ends.
What Sentry is
Sentry monitors running applications: errors, traces, profiles, session replays, logs and metrics, collected by an SDK you add to your application.
“Application performance monitoring for developers & software teams”
Sentry’s own page: https://sentry.io/welcome/, read 2026-11-08
What Sentry does that MLReps does not
What actually happened in production: the exception, the stack trace, the slow transaction, the release it started in. MLReps does not collect errors and has no error inbox.
sentry.io, read 2026-11-08
Session replay and profiling of real users' sessions, which MLReps does not do.
sentry.io, read 2026-11-08
Alerting on production behaviour, from an SDK you drop into the application itself.
sentry.io, read 2026-11-08
What MLReps does that Sentry does not present as its job
The structure behind the error: which module the failing file belongs to, what reaches it, and what a change to it would touch — read from the code, before anything runs.
A performance problem found in the code rather than in a trace: the database query a loop runs once per item of a list, and a read with no limit on it.
Twenty reports on public repositories, so you can read what this produces on a codebase you already know before pointing it at your own.
When to use both
These are complements rather than alternatives, and anybody shipping to production needs the first one. Sentry tells you something broke and where; MLReps tells you what that code is connected to and what changing it will touch.
How to check this page
Every claim above about Sentry links the page it came from and the date it was read. Products change; if one of these is out of date, the link is how you will see that before we do.
The claims about MLReps are checkable a different way: the reports on public repositories are the output itself, on projects nobody chose for us.