What is error tracking?

A checkout fails. You get a report

Someone clicks “Pay”, and your checkout code raises an exception. The customer gets an error page. Your team needs something more useful than “checkout is broken.”

An SDK, a small library you add to the app, can capture the exception and send a report to your error tracker. Handled errors can be reported explicitly, too. What gets captured depends on the SDK and how you configure it.

The report’s message describes the failure. Its stack trace, also called a backtrace, shows the calls that led there and points you toward the relevant code. The release, environment, and recent actions can help explain why it happened. You can see that context in a Telebugs report.

One bug can produce a thousand reports

The same checkout bug may affect dozens of customers before you fix it. An error tracker groups related reports into one issue, so you can investigate the failure in one place. The individual reports are still useful: one may contain the clue that the others don’t.

An alert brings a new failure to your attention. Counts and timestamps help you see whether it’s still happening, while release information can reveal when it started. Configure notifications around what your team needs to act on, so repeated failures don’t drown out new ones.

The report is a starting point

In our checkout example, the backtrace points to code that expects a payment reference. The context your app recorded shows that the provider returned an empty value. You have a concrete case to reproduce, a place to make the change, and a regression test to write.

After deploying the fix, watch for new reports and check the checkout itself. Marking an issue resolved only changes its status in the tracker; it doesn’t change your application’s code.

Error tracking works alongside tests, logs, and uptime checks. Logs can fill in surrounding activity; an uptime check can notice that the site is down. A wrong total that produces no error may never reach the tracker.

Choose where the reports live

Those reports need a home. With a hosted service, the vendor runs the tracker. With self-hosting, you choose the server and look after it, including updates, backups, and storage.

Reports can contain request or user data. Review what the SDK sends, remove secrets and unnecessary personal details before sending, and decide who can read the reports and how long to keep them.

Try it with one error

Telebugs lets you work through this flow on your own server, or on a private instance we manage. Open a report, follow its context, look at related occurrences, and decide what to fix.

To try it, pick your language or framework and send a test error from a development or staging app. Open the report and check that the message, backtrace, and environment help you understand it. That’s the point of error tracking: enough information to take the next useful step.