"We'll hear about it when something breaks." That is the assumption a lot of custom software runs on, and it is wrong. Users rarely report errors: they try again, shrug or leave. By the time someone does call, the error is days old and the context is gone. That is why every application we build ships with error tracking from the first delivery, not as an afterthought.
What error tracking is
Error tracking means every unhandled error in your application reports itself to a central point, the moment it occurs. Not as a bare log line, but with everything attached:
- The stack trace — which line of code, through which calls.
- The release — which version of the application the error occurred in, so you can see whether a deploy introduced it.
- The context — browser or client, the request that failed, and how many users are affected.
Identical errors are grouped into a single issue with a counter, and a new or recurring error triggers an alert. That is the essential difference from log files: in logs you have to go searching, an issue comes to you. The vague complaint "it briefly didn't work yesterday" normally comes with only a time; with error tracking that time comes with a stack trace.
Why we run GlitchTip self-hosted
Error data is not neutral data. A stack trace arrives with request parameters, a session, sometimes the e-mail address of the logged-in user. The well-known trackers are SaaS services, mostly in the United States, and that is where all that context goes — one more processor in your GDPR records, for data you never thought of as "personal data".
So we run GlitchTip: an open-source tracker compatible with the Sentry SDKs, on our own infrastructure. Your application uses the standard library for your language or framework; only the address points at our platform instead of a service overseas. The error data of your application lives on the same infrastructure as the application itself, inside the EU and under our management. The privacy story gets a lot shorter: no extra party is involved.
How it works on our projects
The integration is there at delivery: the SDK is in the application, releases are tagged with every deploy and alerts arrive on the same channels as our infrastructure alerts. In practice this changes the conversation. Without error tracking an outage starts with "could you send a screenshot and tell us exactly what you did?" With error tracking it starts with "we can see it, it is in Tuesday's release, this is the cause." Often that conversation never happens, because the error was fixed before anyone reported it.
If you fall under the NIS2 reporting duty yourself, this is not a luxury either: you cannot report an incident within 24 hours that you only notice after a week.
What it is not
Error tracking is not monitoring. Monitoring tells you whether the service is up: is the server reachable, is there disk space, does the site respond. Error tracking tells you what went wrong in the code, for that one user with that one input, while all the lights are green. A healthy application needs both; one does not replace the other.
Software that reports itself
Error tracking is a standard part of how we build and maintain software: what we deliver, we can demonstrably keep an eye on. If your application runs with us, its error data runs alongside it on our own cloud infrastructure. Want to know what this looks like for your application, or do you currently have an application nobody knows the error rate of: get in touch.