DEV Community: Gabriel Ortuño

Four Mindset Shifts for Teams Adopting Elixir

Gabriel Ortuño — Sun, 04 Oct 2026 07:00:00 +0000

How immutability, explicit data, pattern matching, and result values change software design.

The first warning sign usually appears after the team is already productive.

People know the syntax. They can build Phoenix controllers, write Ecto queries, use pipelines, and get features into production.

And yet the code still feels wrong.

A GenServer starts looking suspiciously like a service object. Pipelines connect functions that return unrelated values. Structs are updated directly from everywhere. Business failures become exceptions. Loops disappear, but the underlying algorithms still assume mutable arrays.

The team has learned Elixir syntax without changing how it thinks about software.

I have worked with Elixir for about a decade and helped many engineers learn it. I have seen the same pattern across different teams and experience levels: the syntax comes quickly. Habits learned in imperative and object-oriented ecosystems take much longer to unlearn.

Experienced developers will learn case, with, and Enum.map/2. One important adoption risk lies elsewhere: whether the team can recognize which familiar assumptions no longer serve them.

If I were introducing Elixir to an experienced engineering team, I would focus much less on syntax and much more on four mindset shifts.

Here is the short version:

Move from mutable state to immutable values.
Move from imperative instructions to declarative transformations.
Move from methods on objects to functions over explicit data.
Move from inspect-then-branch code to patterns and explicit results.

1. From mutable state to immutable values

The inherited habit. In imperative languages, state is commonly represented by values that change over time. An accumulator, object, or array is updated in place, and the algorithm is understood as a sequence of mutations.

Why it creates awkward Elixir. A direct translation tends to reproduce mutation through excessive rebinding, indexed list access, or stateful processes. The syntax changes, but the algorithm still assumes that one location is being updated. This is especially awkward with Elixir lists, which are linked lists rather than mutable arrays: repeatedly accessing elements by position with Enum.at(items, index), or replacing them with List.replace_at(items, index, value), requires traversal and is usually the wrong shape for the problem.

The Elixir mental model. Values do not change. Variables can be rebound, but rebinding points a name at a new value; it does not modify the previous one. A changed user must come from an operation that returns a new value.

user = %User{name: "Ana"}
user = %{user | name: "Anna"}

The second expression creates a new struct and rebinds user; the first struct was never changed. That distinction matters when values cross function or process boundaries. Sharing a value does not give another caller a mutable reference to your copy, so ownership and synchronization do not have to be designed around ordinary in-memory mutation.

This makes local reasoning easier. When reading a function, you can follow the values it receives and returns without wondering whether another reference changed them elsewhere. This is especially useful when several processes receive the same input value.

A representative example. Instead of mutating a running total, pass each intermediate value to the next step:

total =
  Enum.reduce(orders, 0, fn order, accumulator ->
    accumulator + order.amount
  end)

The accumulator is not a mutable location hidden inside the loop. Each call returns the value received by the next call. The useful question becomes: “What should the next value be?”

What I’ve seen in practice. A mistake I have seen many times is building a list by appending every new element with acc ++ [item]. Elixir lists are linked lists, so each append traverses everything accumulated so far. Repeating it turns a linear transformation into an O(n²) algorithm. Prepending with [item | acc] and reversing once at the end keeps it linear. Knowing how the list is represented would have pointed directly to the better implementation.

A code-review question.

Is this code modeling a sequence of values, or reproducing mutation with more complicated syntax?

Do not over-apply the lesson. Elixir programs still have side effects. Functions can write to a database or ETS, send messages, access files, and call external services. Those effects still need careful design. Immutable data structures also have performance characteristics that matter. For example, this is valid:

Enum.at(items, index)

Positional access still traverses the list. In practice, choose data structures and operations that fit the algorithm and make state changes easy to follow.

2. From imperative instructions to declarative transformations

The inherited habit. Imperative code explains how to perform work: initialize a result, control an index, traverse a collection, branch, mutate the result, and continue.

Why it creates awkward Elixir. Translating those mechanics literally produces manual recursion, unnecessary accumulators, or pipelines added only to make code look idiomatic. The reader sees how iteration happens but has to reconstruct what the transformation means.

The Elixir mental model. Describe operations on data and let the abstraction handle the traversal. Functions such as map, filter, and reduce name the transformation being performed. Saving lines is secondary. Elixir control-flow constructs, including if, case, and with, are expressions too: each branch returns a value.

For example, a conditional can produce the next value directly:

status =
  if user.active do
    :available
  else
    :unavailable
  end

The branch returns :available or :unavailable. No outer variable has to be updated.

A representative example. The intent of filtering active users and normalizing their addresses can appear directly in the code:

active_users = Enum.filter(users, &User.active?/1)
emails = Enum.map(active_users, &String.downcase(&1.email))

When normalization has domain meaning, name it:

Enum.map(active_users, &normalized_email/1)

Here, normalized_email/1 tells the reader why the operation exists. The inline version is also fine when lowercasing is all that needs to be said.

The same principle shapes APIs. Put the value being transformed in the first argument so it composes naturally:

user
|> normalize_user(options)
|> validate_user()

An API such as normalize_user(options, user) can work, but it fights the usual direction of the pipe. A well-shaped API makes piping possible; adding |> cannot fix an awkward argument order.

What I’ve seen in practice. I have also seen Enum.each/2 used while a developer tries to keep an accumulator outside the callback. Rebinding a variable inside the anonymous function does not update its outer binding. The code then fails to produce the expected result, or external mutable state is introduced to make it work. Enum.each/2 is intended for side effects. To construct a new collection, use map, filter, or reduce, which return the intermediate state directly.

A code-review question.

Does this code describe a meaningful transformation, or expose iteration and plumbing that an abstraction should own?

Do not over-apply the lesson. Putting everything in a pipeline does not make it declarative. A useful pipeline passes a compatible value from one step to the next and tells a coherent story. When that stops being true, intermediate names, case, or with usually make the code easier to read.

3. From methods on objects to functions over explicit data

The inherited habit. Object-oriented design often bundles data, behavior, identity, and lifecycle into an object. Teams naturally look for the Elixir construct that replaces that bundle.

Why it creates awkward Elixir. Elixir has no single replacement for that bundle. Problems start when structs are updated like mutable objects, use is treated as inheritance, or every domain entity is placed inside a process. These choices mix domain modeling with unrelated runtime mechanisms.

The Elixir mental model. Structs make the shape of domain data explicit, but they do not protect business rules by themselves. Put those rules in named functions that validate and apply each transition. For example, cancelling an order should go through Order.cancel/1 rather than updating %Order{status: ...} directly.

Elixir offers several ways to organize behavior: ordinary functions, behaviours, protocols, and, when compile-time code injection is useful, use. Start with the simplest option that solves the problem, often a function. Introduce a more specialized abstraction only when the requirements justify the additional structure.

A representative example. An Email constructor can validate its input before returning the struct:

defmodule Email do
  defstruct [:value]

  def new(value) when is_binary(value) do
    if valid?(value) do
      {:ok, %__MODULE__{value: value}}
    else
      {:error, :invalid_email}
    end
  end

  defp valid?(value) do
    Regex.match?(~r/^[^\s@]+@[^\s@]+\.[^\s@]+$/, value)
  end
end

The validation rule is deliberately simplified here; the important part is the construction path, not email syntax.

%Email{} remains public because Elixir cannot make struct construction private. Even so, Email.new/1 gives the application one place to reuse the validation rule.

What I’ve seen in practice. I have often seen structs updated from unrelated modules, bypassing the functions that contain the domain rules. Raw maps from external APIs cause a similar problem when they travel through several layers without normalization or a documented shape. Maps are fine at the system boundary. Trouble starts when that transport format becomes the domain model and every caller has to guess which keys exist. Validating the response once and converting it into a known structure gives later code something reliable to work with.

Do not turn every domain entity into a process

A process is a concurrency, lifecycle, and failure boundary, not Elixir's replacement for an object. A GenServer serializes access to its state and can participate in supervision, but that does not make it the natural home for every User, Order, or Invoice.

Keep ordinary domain transformations in functions over data. Introduce a process when the system needs serialization, coordination between callers, ownership of runtime state or resources, or a supervised lifecycle. Create the process because the runtime needs one, not simply because the domain contains an entity.

A code-review question.

Does this abstraction express a domain rule or a real runtime boundary, or is it recreating an object hierarchy with structs, macros, and processes?

Do not over-apply the lesson. Keep domain rules behind functions even when the data is represented explicitly. At the same time, reach for a behaviour, protocol, macro, or GenServer only when the problem requires it. Most ordinary transformations need none of them.

4. From inspect-then-branch code to patterns and explicit results

The inherited habit. Imperative code often accepts a broad value, inspects it inside the function, nests conditionals, and raises exceptions when an expected operation cannot continue.

Why it creates awkward Elixir. The function signature accepts states the implementation cannot actually handle. Basic assumptions only appear later in branches. Expected business failures become exceptions, and broad catch-all clauses can merge outcomes that callers need to distinguish.

The Elixir mental model. Put structural assumptions at function boundaries with patterns and guards. Represent expected outcomes with values such as {:ok, value} and {:error, reason}. Then choose case, with, or a pipe according to the shape of those results.

A representative example. Function clauses can distinguish supported event shapes with non-empty string identifiers, known event types with missing or invalid identifiers, unsupported types, and payloads without a type:

def handle(%{
      "type" => "user.created",
      "user_id" => user_id
    })
    when is_binary(user_id) and user_id != "" do
  create_user_projection(user_id)
end

def handle(%{
      "type" => "user.deleted",
      "user_id" => user_id
    })
    when is_binary(user_id) and user_id != "" do
  delete_user_projection(user_id)
end

def handle(%{"type" => type})
    when type in ["user.created", "user.deleted"] do
  {:error, :invalid_event}
end

def handle(%{"type" => _unsupported_type}) do
  {:error, :unsupported_event}
end

def handle(_payload) do
  {:error, :invalid_event}
end

Each clause shows which input shape it handles. Guards can add constraints on the matched values. Here is a deliberately non-monetary numerical example:

def percentage_of(value, percentage)
    when is_number(value) and is_number(percentage) and
           percentage >= 0 and percentage <= 100 do
  value * percentage / 100
end

Expected business failures can then remain ordinary return values:

{:ok, user}
{:error, :invalid_email}

Use a pipe when each operation accepts the complete value returned by the previous one:

params
|> normalize()
|> build_user()

A pipe does not understand {:ok, value} or {:error, reason} and does not short-circuit automatically. Functions can add clauses that propagate errors, although that moves the control-flow rules away from the call site.

Use with when each step should run only after a particular success shape. The <- clauses show those shapes at the call site, and with returns the first value that does not match:

with {:ok, attrs} <- validate_registration(params),
     {:ok, user} <- create_user(attrs),
     :ok <- publish_user_created(user) do
  {:ok, user}
end

Use case when the alternatives themselves matter:

case Payments.charge(payment) do
  {:ok, receipt} ->
    confirm_payment(receipt)

  {:error, :card_declined} ->
    request_another_payment_method(payment)

  {:error, reason} ->
    handle_payment_error(reason)
end

What I’ve seen in practice. I have often seen a function accept any value and then ask, several times, what it received through nested if and case expressions. case is useful; the issue is that basic validation happens too late. Patterns and guards could reject unsupported inputs at the boundary. I have also seen functions return {:ok, value} when no error outcome exists, exceptions used for recoverable failures, and pipelines connecting incompatible result shapes. Together, these choices leave the caller unsure about what the function will finally return.

A code-review question.

Are the accepted states and expected failures visible at the boundary, and does the control flow preserve their shape?

Do not over-apply the lesson. Return an explicit result when the caller can reasonably recover. Raise when the function's contract is violated or when the caller explicitly chooses a raising API. Be careful with defensive catch-all patterns as well. A broad _ -> may keep the code running while hiding a new state that should force a code change.

Practical implications for evaluating and onboarding a team

When evaluating an Elixir adoption. Learning the syntax is only one part of the work. Look at whether the team is willing to change how it represents state, designs APIs, protects domain rules, introduces concurrency, and communicates failure. A team that keeps its existing architecture and changes only the punctuation will pay for that mismatch in complexity.

These mindset shifts are only one part of technology selection; workload fit, ecosystem coverage, operational maturity, and integration constraints still need separate evaluation.

The four code-review questions in this article provide a practical evaluation framework:

Are we modeling a sequence of values or recreating mutation?
Does the code name the transformation, or expose the iteration mechanics?
Are our abstractions expressing domain rules and real runtime boundaries, or imitating objects?
Can callers tell which inputs are accepted and which failures they can recover from?

When onboarding the team. Organize training around those questions instead of giving only a tour of language features. Pair each mental model with one representative example and revisit it in production code reviews. Teach where a pipe, process, behaviour, or tagged tuple helps, and where it adds unnecessary machinery.

After ten years with Elixir, this is the part I would not leave implicit. Teams usually learn the syntax. The harder work is recognizing the design habits they brought with them and deciding, case by case, whether those habits still fit.

Is Elixir’s Observability Ready for Production? A Guide for Skeptical Engineers

Gabriel Ortuño — Sun, 01 Feb 2026 09:25:31 +0000

As a software engineer coming from ecosystems like the JVM, Go, or Node.js you have a deep understanding of Site Reliability Engineering (SRE) principles and the modern observability stack. You know what it takes to operate systems at scale. When evaluating a new technology like Elixir, a critical question inevitably arises: “Can I really observe and operate this in production?” It’s a valid concern, born from experience with runtimes that can often feel like black boxes.

This article provides a direct, technically-grounded answer to that question. We will explore how Elixir offers a unique, two-pronged observability strategy: unparalleled real-time introspection thanks to its runtime design, combined with full integration into the standardized world of OpenTelemetry and Prometheus. The goal is to demonstrate that Elixir’s observability isn’t just an afterthought; it’s a powerful combination of deep, intrinsic runtime visibility and modern, standards-based instrumentation.

1. A Different Foundation: Observability by Design in the BEAM VM

To understand observability in Elixir, we must first look at its foundation. Elixir runs on the BEAM virtual machine, a core component of the Erlang Run-Time System (ERTS). The BEAM was designed from the ground up for concurrent, fault-tolerant systems, and the ability to inspect a live system is a fundamental part of its architecture, not a feature added later.

Lightweight Processes: The Core of Concurrency

The core unit of execution in an Elixir application is a “process.” Unlike heavyweight OS threads, BEAM processes are extremely lightweight. Each process is an isolated entity with its own stack, heap, and message queue (mailbox), all managed by the BEAM’s preemptive scheduler. This is fundamentally different from OS threads, which are managed by the kernel and have a much larger memory footprint. The BEAM’s ability to manage millions of lightweight processes within a single OS process is central to both its concurrency model and its observability, as the state of every single unit of work is visible to the runtime.

Built-in Introspection with Observer

The most striking feature for engineers new to the BEAM is Observer, a powerful graphical tool that is built directly into the runtime. It allows you to connect to a live Elixir node—in development or production—and inspect its internal state in real-time. This is not a third-party add-on; it’s a core capability of ERTS.

Observer provides critical insights across several areas:

Application Inspection: Visualize the complete supervision tree of your application. This shows exactly how your processes are structured, which processes are supervising others, and how they are linked for fault tolerance.
Process Information: Get a real-time, sortable list of every process running on the node. For each process, you can see its current memory usage, the length of its message queue, and its reduction count—a proxy for how much CPU work it has done. This is invaluable for identifying bottlenecks or memory-hungry processes instantly.
System Overview: View detailed statistics about the BEAM itself, including scheduler utilization across all cores, memory allocator statistics for different data types, and I/O activity.

These same introspection capabilities are available programmatically through functions like erlang:process_info/2, allowing you to build custom monitoring and diagnostic tools that tap directly into the runtime’s own data.

Observer is unparalleled for interactive, live-system debugging, but it is not designed for the automated, long-term, and aggregated analysis required for production SRE practices like alerting and SLO tracking. For that, we turn to the industry-standard three pillars.

2. Bridging to the Familiar: The Three Pillars in Elixir

While Observer provides a powerful ‘point-in-time’ view into the VM, a robust observability strategy also requires historical data and distributed context. This is where the ecosystem bridges from its unique internal capabilities to the familiar ‘three pillars’ model, with the telemetry library serving as the cornerstone.

The Foundation: telemetry

Telemetry is a lightweight, universal event-dispatching library that has become the standard foundation for instrumentation in Elixir. Key libraries like the Phoenix web framework and the Ecto database wrapper use telemetry to emit standardized events about their internal operations (e.g., request timings, query performance). Other libraries can then attach to these events to generate logs, metrics, or traces. This architecture decouples instrumentation from consumption. Library authors (like the Phoenix team) can emit events without dictating how they are used, allowing operations teams to plug in any number of handlers for metrics, logging, or tracing without modifying the core library code. This is a crucial design choice for a flexible and maintainable ecosystem.

The Three Pillars of Observability

This telemetry-based approach provides a clean bridge to the three pillars of observability, which are essential for understanding the why behind a system’s behavior, not just the what.

Logs: Discrete, timestamped records of events. They are essential for troubleshooting specific occurrences, providing the rich, detailed context needed to understand the steps leading to an error or a specific transaction.
Metrics: Aggregated numerical representations of system health over time (e.g., request latency, error rates, CPU utilization). They are ideal for building dashboards, defining alerts on known thresholds, and analyzing historical trends.
Traces: A detailed view of a single request’s end-to-end journey as it flows through a distributed system. Traces are crucial for diagnosing latency issues, identifying bottlenecks, and understanding inter-service dependencies in a microservices architecture.

The telemetry library provides the universal event bus that allows specialized libraries to transform raw events into the metrics and traces needed for a complete observability picture.

3. Logs: Structured Logging as a First-Class Citizen

Before discussing metrics and dashboards, it’s worth addressing logging, because this is often the first observability signal teams rely on in production—and an area where Elixir is frequently underestimated.

Elixir’s logging system is built around the Logger module, which is part of the standard library and deeply integrated with the runtime. While Logger historically emitted plain text logs by default, modern Elixir applications almost universally use structured logging, and the ecosystem makes this both straightforward and idiomatic.

Structured Logs by Default, Not by Convention

Logger supports structured, key–value metadata natively. Instead of treating logs as unstructured strings that must later be parsed, Elixir encourages attaching contextual metadata—such as request IDs, user identifiers, or domain-specific fields—directly to log events.

This metadata propagates naturally through the process model, meaning contextual information (like a request ID set at the boundary of a web request) is automatically available to all logs emitted by that process and its children. This aligns well with modern logging practices and avoids the need for thread-local hacks or manual context passing common in other ecosystems.

Flexible Encoding and Output

In production, Logger can be configured to emit logs in structured formats such as JSON, making it trivial to integrate with standard log aggregation systems (e.g., Elasticsearch, Loki, or commercial SaaS platforms). This is typically achieved by swapping the default formatter for a JSON formatter, without changing application code.

Because Logger is part of the runtime and not a third-party abstraction, this configuration is:

Centralized
Consistent across the ecosystem
Decoupled from any specific log backend

This makes it easy to evolve logging strategies over time—from local development logs to fully structured production pipelines—without rewriting instrumentation.

Logs as Part of a Cohesive Observability Strategy

Crucially, logging in Elixir does not exist in isolation. Logger integrates cleanly with the broader observability stack:

Logs can include trace and span identifiers when OpenTelemetry is enabled
Log volume and levels can be dynamically adjusted at runtime
Logging remains lightweight, with backpressure handled by the BEAM rather than the application

The result is a logging system that feels modern, production-oriented, and aligned with today’s expectations: structured by default, context-aware, and easy to route into both open-source and commercial observability platforms.

When OpenTelemetry is enabled, this structured logging model becomes even more powerful. Trace and span identifiers (trace_id, span_id) can be automatically injected into Logger metadata, allowing logs to be directly correlated with distributed traces. This makes it trivial to pivot from a slow or failing trace to the exact log lines emitted within that span, using standard tooling in both open-source and commercial platforms. For teams used to trace–log correlation in JVM or Go-based systems, this behavior is fully supported and idiomatic in Elixir.

4. Metrics: The Prometheus & Grafana Story

For metrics, the Elixir ecosystem has a go-to solution for integrating with the industry-standard Prometheus and Grafana stack: PromEx.

PromEx is a library designed to make exposing Prometheus-compatible metrics from an Elixir application as simple and streamlined as possible. It works by attaching its own handlers to the telemetry events emitted by your application and its dependencies, converting them into the metrics format that Prometheus scrapes.

The setup and features highlight its power and ease of use:

Simple Configuration: A single mix task, mix prom_ex.gen.config, generates the necessary configuration module, removing boilerplate and guesswork.
Effortless Phoenix Integration: PromEx.Plug is a simple plug that can be added to your Phoenix endpoint to expose a /metrics endpoint. Prometheus can then be configured to scrape this endpoint automatically.
Rich Ecosystem Plugins: PromEx offers a suite of pre-built plugins that provide deep visibility into the most common parts of an Elixir stack, including:
- PromEx.Plugins.Beam (for BEAM VM metrics)
- PromEx.Plugins.Phoenix (for web request metrics)
- PromEx.Plugins.Ecto (for database query metrics)
- PromEx.Plugins.Oban (for background job processing metrics)
Pre-built Dashboards: Crucially, each plugin comes with a tailored Grafana dashboard. This means you get meaningful, out-of-the-box visualizations for your key metrics without having to build dashboards from scratch.

5. Tracing: Embracing the OpenTelemetry Standard

For distributed tracing, the Elixir community has fully adopted OpenTelemetry (OTel), the Cloud Native Computing Foundation (CNCF) framework that provides a vendor-neutral standard for generating and collecting telemetry data.

Core Components and Instrumentation

Setting up OTel in a typical Phoenix application involves adding a few key libraries: opentelemetry_api, opentelemetry, and instrumentation-specific packages like opentelemetry_phoenix.

Instrumentation works in two primary ways:

Automatic Instrumentation: Libraries like opentelemetry_phoenix listen for standard :telemetry events and automatically create OTel spans from them. This provides a baseline level of tracing for web requests and database queries with minimal setup.
Manual Instrumentation: For business-logic-specific insights, you can create custom spans programmatically using functions like Tracer.with_span. This is essential for tracing business-critical logic that isn’t captured by default framework events, such as the steps within a complex financial transaction or a multi-stage data processing pipeline.

Exporting Data via the OTel Collector

The best practice for sending telemetry data in production is to use the OpenTelemetry Collector. This is a vendor-agnostic agent that receives data from your application (typically via the OTLP protocol) and can then process and export it to any number of backends. This decouples your application from the specific tracing backend (e.g., Jaeger, Zipkin, or a commercial platform), preventing vendor lock-in.

A Note on Maturity and Performance

The OpenTelemetry SDK for Elixir/Erlang is mature and widely used in production. However, for systems with very high request throughput, some performance tuning may be required. Specifically, operators may need to adjust the configuration of the batch span processor (e.g., OTEL_BSP_SCHEDULE_DELAY_MILLIS) to balance memory usage and latency, ensuring the observability layer itself does not become a bottleneck.

One important distinction to be explicit about is profiling. Unlike the JVM (JFR) or Go (pprof), the BEAM does not yet offer a ubiquitous, always-on, low-overhead continuous profiler as part of the standard production toolchain. Instead, profiling in Elixir relies on a combination of built-in tools (:eprof, :fprof, :cprof), runtime introspection, and situational diagnostics using Observer or libraries like recon. This means profiling is typically more targeted and investigative rather than continuously sampled. For many teams this is sufficient—especially when combined with strong metrics and tracing—but it is a real trade-off to be aware of for workloads where continuous CPU or allocation profiling is a hard requirement.

6. Integrating with Commercial Platforms (Datadog, New Relic, AppSignal, etc.)

Elixir applications integrate reliably with major commercial observability platforms such as Datadog, New Relic, and AppSignal. For most production systems today, the recommended and future-proof integration path is OpenTelemetry, which provides a vendor-neutral foundation for traces, metrics, and logs.

By instrumenting your application using OpenTelemetry APIs, you decouple observability concerns from any specific backend. Telemetry data is typically exported to an OpenTelemetry Collector, which then forwards it to one or more destinations—self-hosted systems like Jaeger or Prometheus, or commercial platforms such as Datadog or New Relic. Switching backends does not require changes to application code; it is a configuration concern at the Collector level.

This OTel-first approach has two important implications:

Consistency and portability: Instrumentation remains stable even if vendors change, pricing shifts, or organizational preferences evolve.
Reduced vendor lock-in: The application depends on open standards rather than proprietary agents or SDKs.

Some platforms also offer Elixir-specific or vendor-native integrations. AppSignal, in particular, provides a tightly integrated, Elixir-first experience with minimal setup and strong defaults. This can be an attractive option for teams that prefer a managed solution and are comfortable trading some flexibility for simplicity. However, such integrations typically couple instrumentation more closely to the vendor and make later migrations more expensive.

At a high level, the trade-off is familiar:

Self-Hosted Open Source (Prometheus / Grafana / Jaeger): Maximum control and flexibility with no direct vendor costs. Requires operational ownership and expertise.
Commercial SaaS Platforms: Managed infrastructure, advanced analytics, and lower operational overhead. Cost scales with usage.

In practice, many teams adopt a hybrid model: open-source tooling for core metrics and dashboards, combined with commercial platforms for tracing, alerting, or cross-service analysis. Elixir’s OpenTelemetry-based integrations support this model well.

7. The Verdict: Is Elixir Production-Ready?

So, is Elixir’s observability stack ready for the demands of modern production systems? The answer is yes. The ecosystem provides a clear two-pronged approach: deep, real-time runtime introspection via the BEAM, combined with full support for industry-standard observability practices through Telemetry, OpenTelemetry, and Prometheus-based tooling.

The BEAM’s intrinsic visibility enables operators to inspect scheduler behavior, memory usage, and individual process state directly on a live system, answering the question “what is happening right now?” with a level of precision that is difficult to achieve in many other runtimes. At the same time, standardized metrics, logs, and traces provide the historical context required for alerting, SLOs, and distributed debugging.

This contrasts with platforms where the runtime is largely opaque and observability relies primarily on sampling and post-hoc inference. In JVM or Go ecosystems, visibility is often reconstructed from external signals; in the BEAM, it is exposed directly by the runtime itself.

That said, Elixir’s observability model will not be a perfect fit for every organization. Teams that depend heavily on always-on, low-overhead continuous profiling, that are unwilling to operate BEAM-specific tooling, or that mandate vendor-specific agents may find a more natural fit elsewhere. Elixir rewards teams willing to understand the runtime it runs on—and for those teams, it offers a level of operational transparency that is difficult to replicate.