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
https://github.com/elixir-error-tracker/error-tracker
Screenshots
Trending in Announcing
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance












First 10 of 56 Posts
zachdaniel
This is very cool
ghannam80
That is great. just yesterday I was looking for phoenix related monitoring and logging related libraries or configuration monitoring
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
frankdugan3
Very nice! Are there plans to add a JS package to handle catching client-side errors?
ghannam80
It is really a good start
If you are accepting suggestions for roadmap maybe real time tracking , performance metrics and notifications/alerts .
I think those would be more than enough for most monitoring needs.
ivanov
Thank you for building and releasing this. I had “install and integrate Sentry” on my TODO list that I will now happily cross off as ErrorTracker is a very suitable lightweight replacement. (I wanted this introspection, but the whole project I’m using will be running on less than Sentry’s self-hosted minimum system requirements.
Was able to quickly install and demo it during today’s frelix meeting ( local thread )
cmo
Can/will it handle errors from other applications or is it just for the single node?
jan-mb-me
@belaustegui, thank you for publishing this.
I think it would be great to be able to delete errors, too, since they might contain data one doesn’t want to keep forever (f.i. due to GDPR and the like).
ghannam80
It could be a configuration to enable/disable it in logging. As in example in payments most loggers come with capability to configure sensitive data fields like card number which should be logged as masked or never
spaceCowboy
This looks fantastic! Can’t wait to give it a try! Felicitaciones!