belaustegui
ErrorTracker - an Elixir-based built-in error tracking solution
Announcing ErrorTracker, an Elixir-based built-in error tracking solution.
Features
- Basic, free, built-in error tracking solution. Tracking errors in your application should be a requirement for almost any project and it helps to improve quality and maintenance.
- Easy to set up. Includes plug-and-play integrations that work automatically such as:
- Plug integration
- Phoenix integration
- Oban integration
- Minimalistic. You just need a relational database to store errors. It can be your application’s database or a separate one.
- Web UI. Includes a LiveView dashboard that allows you to search, manage and resolve recorded errors.
- Extra context. Recorded errors include additional context such as the request path or the LiveView event for the Phoenix integration and the job ID and parameters for the Oban integration. You can also add your additional context.
What makes ErrorTracker different?
ErrorTracker does not require you to rely on third party services to track your errors. Your errors, just like your data, are yours. You decide where to store them, when to prune them and how to manage them.
This is invaluable for a whole set of applications that handle PII data and must maintain a high level of care when sharing that data with third parties. No need to worry whether the third party complies with HIPAA, GDPR, etc. as your data won’t leave your systems.
This is also highly beneficial for small projects that can’t afford to pay a third party service for tracking errors. Without this observability, errors are hard to debug and fix. The ErrorTracker allows you to track errors for free in your current system and may provide this observability capabilities that will help you reproduce and fix errors easily.
Useful links
Screenshots
Most Liked
odarriba
Version 0.2.0 is out!
This update includes several improvements to the library:
- SQLite 3 compatibility (including a better way to track database schema versions)
- Telemetry events - can be used to integrate your own notifications
- UI improvements - more refined styles and UX
- A better test suite, including testing in both RDBMS and different Elixir/Erlang versions in the CI
If you are already using the library: there is a new version of the DB schema, so you need to create a new migration to migrate to version 2.
We hope this version fixes some of the issues reported
any feedback is welcome!
jaimeiniesta
Hey ErrorTracker team, thanks a lot for your effort in putting this together! I already fixed an error thanks to your library ![]()
Please consider adding a way to sponsor the project, it will surely be well-received by the community.
odarriba
We’ve been working on this for the last month and a half
There are a lot of things to polish yet, but we believe it is a good starting point to release it.
As for now it only tracks exceptions and not performance, but the base is there to add more features in the future ![]()
ivanhercaz
I am already working on the suggestion I did some days ago:
If everything goes well, I think I could release a first release of the package this weekend. I will notice you!
odarriba
That makes sense, because V02 in PostgreSQL systems creates a new table to store meta information and moves the information about which migration version is the latest to that table.
Tables and structures used by ErrorTracker are not changed - we may use the new error_tracker_meta table in the future, but not now - so the system will work without that migration but it is really recommended to stay up to date.
As we migrated how the schema version number is stored - and it is an important information to take into account on the migration process - that migration is different to others, but we have tested it and should work as expected.
That’s the issue! We should have included that in the release message, but the idea is to have it like:
defmodule MyApp.Repo.Migrations.UpdateErrorTrackerToV02 do
use Ecto.Migration
def up, do: ErrorTracker.Migration.up(version: 2)
def down, do: ErrorTracker.Migration.down(version: 2)
end
which produces this output when migrating:
15:42:49.730 [info] == Running 20240814134232 MyApp.Repo.Migrations.UpdateErrorTrackerToV02.up/0 forward
15:42:49.764 [info] create table if not exists public.error_tracker_meta
15:42:49.800 [info] execute "COMMENT ON TABLE \"public\".error_tracker_errors IS ''"
15:42:49.801 [info] execute "INSERT INTO public.error_tracker_meta (key, value)\nVALUES ('migration_version', '2'), ('migration_timestamp', '1723642969')\nON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value\n"
15:42:49.807 [info] == Migrated 20240814134232 in 0.0s
in the way you created it works fine if you go up, but on the down it will remove all migrations, so reverting the other one will result in errors because tables don’t exist anymore.
Yes!
Hope it helps!! If you have more issues please feel free to open an issue and we can find a solution there.










