: We built and open sourced a new Elixir package called 

 that provides Elixir Exception Tracking with many pre-built reporting options available, including E-mail, Slack, local ErrorTracker and popular 3rd party services.

Elixir is well known for it's easy way of building applications that, almost naturally, can tolerate faults fairly well.

This is mainly a consequence of how Erlang (and though Elixir) programs are, by design, run as a collection of small and isolated processes supervised by special processes called supervisors that act (mostly restart them based on different strategies) when their "child" processes exit abnormally.

However, doesn't mean that one should ignore any error in any process of a running Elixir application.

Something goes wrong for one or some amount of processes, they terminate their execution abnormally, and a supervisor takes care of re-starting these with clean state. It is truly great that this mechanism makes you're application tolerant to the error, the fact that it contained, isolated, and that it didn't brought your whole application down.

But you still want to be informed about whatever gone wrong, so that you can understand, troubleshoot and fix whatever needs fixing, to prevent it from happening again if possible or prevent worse consequences.

So, exception tracking and reporting, is still very important for Elixir applications as it is for other programming languages.

When it comes to writing code to listen and be aware of all exceptions occurring in a running Elixir application, it's not as trivial as it can be with other programming languages that are naturally single-threaded. Writing a simple "try-rescue" wrapper in an application "entry point" won't work, because there is no such thing as a main entry or main function.

Any Elixir application is highly concurrent. Many processes will be started concurrently during boot time. Not only the main application supervisor's  children defined in the 

 file will run concurrently, but potentially also a lot of the dependencies listed in 

 project deps, may have defined their own "application" that Elixir will also run concurrently along yours.

 behaviour can be useful to be handle all the exceptions happening in processes executing plug calls, i.e. executing the code responding to web requests, like a Phoenix controller action function. However, it won't be informed about exceptions happening elsewhere, in backgrounds processes like Oban jobs, or any concurrent processes part of your supervision tree or dependencies supervision trees, or even in an unlinked task (with 

Whether these omissions are a deal-breaker might depend on each one.

They are for me, I won't feel comfortable running an application in production for which I won't be informed of all exceptions, except the ones I intentionally silenced. I'd rather be informed by an error tracker first than by a customer.

A second and more general-purpose approach is implementing a logger handler.

For a long time in Elixir this wasn't a well generalized and solid solution for this, until a substantial change landed in Elixir 1.15 with the full integration of Elixir's 

Details probably deserve their own article but in summary it means that one can easily define what is called a "logger handler" and listen to all, or a filtered subset of, logged events in the running applications, which include exceptions in any abnormally terminating process.

This will listen to any exception "crashing" any running Elixir process.

Raised exceptions that are manually handled (via rescue or catch) by application code or your dependencies code, that aren't re-raised won't actually "crash", so it won't land on the logger, unless the handling code manually sends a log message to the logger including the 

An example of these "silent" exceptions are those occurring inside Oban job execution. For those particular situations, hopefully the library emits 

 events with the exception information, which is the case for Oban. That means that in addition to a logger handler you may need a few additional Telemetry event handlers as add-ons for special cases.

Cool. We found a way to listen to any exception occurring in any concurrent process in the whole runtime or supervision trees of the different running applications.

All of the above and discussed so far, in a nutshell, is what 

 does, a package we build for ourselves at Mimiquate and open sourced.

At its core it is a universal exception tracker, that bundles the exception data into a well-defined Elixir struct called a 

 and passes these along to any number of reporters. So we say is agnostic to reporting destination, meaning it's not coupled with Exception Monitoring Services, E-mail or Slack or any other.

To report to one any number of destinations you can depend on separate Elixir packages that we built, or write your own.

Set a few Sentry-specific config settings.

Automatic reporting of exceptions will “just work”.

 anywhere you like in your application code, like so:

You need or want to switch service from Sentry to Honeybadger.

config :tower, reporters: [TowerHoneybadger]

Add Honeybadger-specific config, like setting API Key.

Automatic reporting of exceptions continues to “just work” without any changes.

 throughout your application code unchanged.

You are reporting to Sentry and you want to test ErrorTracker while continuing to report to Sentry.

Follow a few ErrorTracker specific configs.

config :tower, reporters: [TowerSentry, TowerErrorTracker]

Automatic reporting of exceptions continue to “just work” without any changes.

Now you will have exceptions reported to both Sentry and ErrorTracker.

Tower: Universal and Agnostic Elixir Exception Tracker

After eight years of growth and evolution, we’re thrilled to unveil a fresh look for our brand, along with an updated website and a brand-new blog. This rebranding marks a key milestone in Mimiquate’s journey, helping us better communicate who we are today and share more about what excites us—especially the projects and events we’re involved in.

When Marcelo and I first founded Mimiquate, it was just the two of us. Our goal back then was simple: create a brand that looked great online and could be easily shown to potential clients as we traveled to conferences. It was essential that the brand reflected our commitment to adapting to our clients’ needs—something we still prioritize today.

One of the things we loved most was our original mascot, the chameleon. It wasn’t just a fun symbol; it represented our core value—adaptability to our clients. Just like a chameleon changes its colors to fit its environment, we prided ourselves on being flexible and responsive to the challenges and requirements our clients presented. However, as time passed, we realized that while the mascot worked well digitally, it became tricky to use in other formats like print. Logos were more complex back then, but the industry has since shifted towards simplicity.

We took a practical approach to our first website, too. Using a $20 template from an online gallery, we customized it to fit our needs. At the time, it was the perfect solution: affordable, quick, and functional, with a fantastic return on investment for our young company.

As Mimiquate grew, balancing branding with the demands of the business became more difficult. Both Marcelo and I were coding full-time, so naturally, marketing efforts took a back seat. Now, eight years later, with a team of 30, we finally have the opportunity to focus more strategically on enhancing the company’s image.

Our original brand started to feel outdated, especially with the industry trend toward cleaner, more modern designs. What once symbolized our adaptability began to feel too complex. So, we knew it was time for a refresh.

For this redesign, we chose to work with the creators of our original brand, Barbudo Estudio, because of the great experience we had with them before. This time, we wanted a more modern, approachable look that reflects our growth while staying true to our core values.

A key difference with this rebrand is that we involved our entire team in the process. As Mimiquate has expanded, we felt it was important for the brand to represent all of us, not just the founders. The result is a fresh, unified look that we’re all proud to share.

Our rebranding didn’t stop at just the logo. We also set out to completely redesign our website to better showcase who we are today and the work we do. To bring this vision to life, we teamed up with our friends at Purple Bunny, who handled everything from design to copy and implementation.

One of the most exciting aspects of the new website is the launch of our blog. We’ll use this space to dive into technical content, share updates on the events we organize and sponsor—including the Elixir Montevideo meetup—and talk about other company-related initiatives. We’re excited to connect with our community in a more personal way through these posts.

Mimiquate's New Look and Blog

At Mimiquate, we are strong believers in the power of in-person community events. There's something unique about being physically present that fosters unity, collaboration, and shared enthusiasm. Over the years, we have seen how events like ElixirConf serve as the heart of the Elixir community, connecting developers, companies, and enthusiasts alike. That’s why, for several years now, we’ve proudly sponsored ElixirConf—and 2024 was no different.

ElixirConf 2024 – More Like LivebookConf!

This year’s conference had us joking that it felt like "LivebookConf," with so much focus on livebooks and their ever-growing influence in the Elixir ecosystem. But in all seriousness, the event was packed with inspiring talks, groundbreaking projects, and fascinating use cases that show the continued evolution of Elixir and its community.

The keynotes were, as always, the heartbeat of the conference, offering deep insights and new perspectives. Here are a few standouts:

: These two titans showcased how to spin up 

 machines to perform parallel machine learning tasks, leveraging Elixir for a seamless experience. This method, coupled with the power of Livebook, opens up exciting possibilities for data scientists experimenting with new models. The prospect of bringing Elixir closer to the world of data science is an exciting development!

: Theo’s talk brought a fresh breeze to the ElixirConf stage. Coming from the JavaScript community, Theo’s presence was a nice reminder of how valuable cross-community dialogue can be. His talk was personal, yet relatable to developers from all backgrounds, and his insights bridged the gap between Elixir and the wider programming world.

: José never disappoints. This year, he reflected on 20 years of web development history while also looking ahead at what's to come. One of the most intriguing parts of his talk was an experimental project (now archived) that explored syncing frontend and backend changes through database replication, offering an alternative to LiveView that collapses layers in a new way. It was thought-provoking, even if the project was just an experiment.

: Closing the conference with an inspiring talk, Justin Schneck explored the potential of household technology and how we can leverage it to enhance mental health. His message was not only technically impressive but also a reminder of the broader, positive impact technology can have on our daily lives.

Beyond the keynotes, there were plenty of other excellent talks to check out, especially if you missed the event:

: These talks demonstrated the growing versatility of Livebook in experimentation, teaching, and more.

: Guillaume took us through a live demonstration of building out Elixir’s type system. It was fascinating to watch such an intricate process unfold live on stage.

: Chris’s deep dive into working with Materialized Views in Ecto brought some exciting database concepts to the forefront of the conference.

: Their talk on how Elixir developers can engineer their career progression and promotions was both practical and motivating—great for anyone looking to level up their career.

: Wojtek’s session on rapid prototyping in Elixir was packed with useful takeaways for developers looking to get the most out of their projects quickly.

As always, we’re already looking forward to next year’s ElixirConf. It’s such an important event for us, and we plan on continuing to sponsor and support it. I’ll be there with my instant camera again, capturing memories and making new friends.

One thing we hope to see more of in the future is a more welcoming atmosphere for people outside the Elixir community. Bringing fresh perspectives, like Theo’s, is invaluable, and we’d love to see even more diverse voices at these events.

Mimiquate Blog

Tower: Universal and Agnostic Elixir Exception Tracker

Tower: Universal and Agnostic Elixir Exception Tracker

Mimiquate's New Look and Blog

Recap ElixirConf 2024