Bugsink

Error reports carry the same sensitive material as the application that produced them: user identifiers, email addresses, session tokens, whatever was in scope when the exception fired. Scrubbing all of that before shipping it to a third party is never finished work, and a missed field stays undetectable until it leaks. Bugsink keeps error tracking on hardware you control instead.

Your application reports through an SDK and Bugsink is the server that receives, groups, and displays what arrives. It is compatible with Sentry's open source SDKs, so connecting an existing project means changing a DSN rather than rewriting instrumentation. Evaluating it takes one docker run, after which the interface answers on port 8000.

The interface is arranged around the moment you actually need it, when something has broken in production.

• Stacktrace first: the full call stack sits at the top of the page rather than behind an expander.
• Local variables: the values held at the time of the error are shown alongside the code.
• Frame separation: in-app frames are distinguished from library frames so attention lands in the right place.
• Alerts: notifications fire on new issues, regressions, and issues whose mute period has expired.
• Smart retention: events are sampled by issue volume and age, so disks fill slowly instead of hitting a quota.

Published figures put throughput at 18 events per second on a two-core virtual machine with 4GB of memory, and the stress test scripts ship with the code so you can check that yourself. MySQL and PostgreSQL are both supported.