ErrorTracker: error tracking that lives inside your Elixir application

Error tracking that runs inside the application

Most error tracking tools run somewhere else. A browser beacon posts a payload to a hosted service, the service groups the events, and the team reads them on the vendor's dashboard. ErrorTracker takes a different position. It is a Hex package that runs as part of your Elixir application, captures errors there, and stores them in your own database.

That single decision changes the data flow. The README states that ErrorTracker captures errors in your application and stores them in the database, and that it provides a web dashboard where captured errors can be found, inspected and resolved. The dashboard and the data live on the same infrastructure as the application that produced the failures, which is the point the project makes when it argues that you keep full control over where, how and what data is stored.

The audience is narrow and clearly defined: developers running Elixir services, with Phoenix and Phoenix LiveView appearing among the project topics, who want error history they own rather than error history a vendor holds. The homepage is the package page on hex.pm, and the README points to a separate document for configuration.

Capture, storage, and a dashboard for resolving

The mechanism has three moving parts. First, errors are captured inside the running application. Second, they are written to the database rather than to a log pipeline or a socket. Third, the web dashboard reads them back and lets someone work through them.

That structure is why the repository carries assets and a LiveView-flavoured front end. The README notes that the JavaScript is not expected to change much because the project relies on LiveView, and that the CSS is generated by Tailwind. In other words, the dashboard is a live page that renders as data changes, rather than a static report generator.

The repository layout matches the shape: lib/ for the library code, assets/ for the dashboard front end, priv/ for static assets, config/ for configuration, test/ for the test suite, and guides/ for documentation including the Getting Started guide. There is also a CHANGELOG.md at the top level and a LICENSE file. What the README does not describe is the schema of the stored errors, the retention policy, or how many records the dashboard paginates through. If retention matters to you, that is a question for the source, not for the README.

Telemetry is the seam, notifications are your job

The README is unusually direct about scope. Under the heading about notifications and issue trackers it says the goal is to track errors, period, and that the project provides a Telemetry integration which you can attach to in order to send notifications, open tickets in an issue tracker and similar things.

So the alerting story is deliberately empty out of the box. There is no Slack webhook, no ticket creation, no email dispatch baked into the package. What you get is a hook: Telemetry events emitted by the library that your own code can subscribe to and turn into whatever workflow you want. Writing that subscriber is the work the package leaves to you.

This is the design decision worth understanding before you commit. If your team already has a telemetry subscriber that forwards events to a pager, a chat channel or a tracker, ErrorTracker fits into it cleanly. If your team wants error alerts to work the afternoon you install a package, this is the wrong shape and you will write that integration yourself. The same applies to deduplication, grouping by fingerprint and noise control, none of which the README describes.

The commands the README documents are for contributors

There is no installation walkthrough for users in the README. It points to the Getting Started guide for configuration and to the package page on hex.pm for the package itself, which is where a new user should start. The commands printed in the README are for people working on ErrorTracker itself, and they are worth reading because they reveal the shape of the project.

The first step copies the example configuration files so that they can be edited for a local environment:

cp config/dev.example.exs config/dev.exs
cp config/test.example.exs config/test.exs

The dependencies then come down from the Mix registry:

mix deps.get

The web UI assets need a clean build, and the README says this task compiles the JavaScript and CSS:

mix do assets.install, assets.build

Since the CSS is generated automatically by Tailwind, changing classes means running the watcher in a separate terminal:

mix assets.watch

For running the project locally, the README points to a dev.exs script based on Phoenix Playground that starts a development server:

iex dev.exs

Two things are missing even for contributors: no mention of how the test suite is invoked, and no note about where the dashboard route gets mounted in a host application. Both live outside the README.

Release history, licence, and the question of alternatives

The release record is short and regular. Tagged versions include v0.7.1 on 2025-12-23, v0.8.0 on 2026-03-01 and v0.9.0 on 2026-05-03. The repository is not archived, and the last push was on 2026-10-01, so commits continue after the newest tag. A version below 1.0 tells you the API surface can still shift, which matters when you are considering building a subscriber on top of the telemetry events.

Licensing is straightforward. The project is released under Apache-2.0, with the LICENSE file at the repository root, and it is distributed as a normal Hex package rather than a hosted service with per-seat pricing.

The obvious alternative is a SaaS error tracker, and the README names that category directly. The difference in approach is where the data goes and who handles the incident workflow. A hosted tracker takes ownership of ingestion, storage, alerting and the user interface, and gives you a vendor support path and a mature feature set for the price of sending your stack traces outside your system. ErrorTracker keeps the database and the dashboard inside your deployment and hands you the integration seam instead of the integrations. The trade is yours to make, and it depends on whether data residency or alert workflow matters more to you than time to first alert.

Editorial conclusion

ErrorTracker fits teams running Elixir services that need a searchable error history inside their own database and would rather not ship stack traces to a third party, and teams willing to build their own alerting on top of a Telemetry hook. It is the wrong choice if you need out-of-the-box notifications, issue tracker integration or a support contract, since the README states those are out of scope. Before adopting, read the Getting Started guide linked from the README, confirm the dashboard is mounted in your router, and check the release history, where the newest tag is v0.9.0 from 2026-05-03 while the last push was on 2026-10-01.

Frequently asked questions

Official sources

1. elixir-error-tracker/error-tracker on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases