Error Tracking for Phoenix Apps

Phoenix Elixir error monitoring is becoming critical as more teams adopt Elixir's fault-tolerant runtime for production systems. Unlike traditional request-response architectures, Elixir processes crash independently, spawn supervisors, and restart with minimal visibility—unless you're actively tracking what went wrong. By the time you hear about an issue from a user, the process has already restarted, losing the context of why it failed. Error tracking gives you the breadcrumbs, stack traces, and contextual data you need to debug distributed failures in Elixir applications without guesswork.

The Phoenix ecosystem has specialized tools like Honeybadger and AppSignal that work well for Erlang/Elixir, but if you're already using Sentry SDKs in other projects (Node.js frontends, Python services, Java backends), you'll want a unified error tracking solution. That's where LightTrace comes in—it speaks the Sentry protocol, so any Sentry SDK can point to it, and it gives you the same comprehensive error tracking (stack traces, breadcrumbs, release health, distributed tracing) at a fraction of the cost of Sentry itself.

Why Phoenix Needs Error Tracking

Elixir's "let it crash" philosophy is powerful: processes fail safely, supervisors restart them, and your application stays up. But silence isn't reliability. When a GenServer crashes, a child process exits, or a background job fails silently, you need to know. Error tracking transforms silent failures into actionable intelligence.

Traditional logging is reactive—you SSH into a server or scan centralized logs after something goes wrong. Error tracking is proactive. It:

• Groups related errors into fingerprinted issues, so you see patterns ("this error happens 50 times a day") instead of noise.
• Captures full context: stack traces, request parameters, user IDs, release version, environment, and custom tags—all in one place.
• Enables alerting: new critical issues trigger alerts so your team knows immediately.
• Integrates with your workflow: link stack frames directly to GitHub, attach release metadata, and correlate errors with deployments.

For error tracking in general, the principles are the same. But Elixir has unique needs: you're tracking process crashes, exceptions in supervision trees, and potentially hundreds of worker processes hitting the same bug simultaneously.

The Current Elixir Landscape

Honeybadger and AppSignal are the established players in Elixir error tracking. Both offer native Erlang/Elixir libraries, excellent documentation, and deep integrations with Phoenix. If you're happy with them, great—they're solid products.

But if you're running Sentry SDKs elsewhere in your stack—say, a Node.js frontend with @sentry/browser or a Python microservice with sentry-sdk—you face vendor sprawl. Each tool has its own UI, pricing model, and data silos. You're paying for Sentry on frontend, AppSignal on backend, and somehow trying to correlate transactions across systems.

LightTrace solves this by accepting the Sentry protocol everywhere. You can point your Elixir app and your Node frontend and your Kafka consumers all at the same LightTrace instance using their native Sentry SDKs. One dashboard, one set of alerts, one contract.

Connecting Elixir to LightTrace

The Sentry Elixir library (sentry) is the official Sentry SDK for Elixir. It works with LightTrace because LightTrace is Sentry-protocol compatible. Start by adding it to your mix.exs:

defp deps do
  [
    {:sentry, "~> 8.0"},
    {:jason, "~> 1.0"}
  ]
end

Then configure it in your config.exs:

config :sentry,
  dsn: "https://YOUR_KEY@light-trace.robomiri.com/1",
  environment_name: Mix.env(),
  enable_in_prod: true,
  included_environments: [:prod],
  release: System.get_env("RELEASE_VERSION", "unknown")

(Replace light-trace.robomiri.com with your actual LightTrace instance and YOUR_KEY with your project's Sentry key from the LightTrace dashboard.)

Then initialize it early in your supervision tree—typically in your main application module:

defmodule MyApp.Application do
  use Application

  @impl true
  def start(_type, _args) do
    :ok = Sentry.init()

    children = [
      MyApp.Repo,
      {Phoenix.PubSub, name: MyApp.PubSub},
      MyApp.Endpoint
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

The SDK will now capture unhandled exceptions and report them to LightTrace. No manual try-catch blocks needed—it hooks into Erlang's error logger.

Capturing Context and Custom Events

The real power of error tracking comes from context. When an error lands, you want to know what the user was doing, what inputs triggered it, and what your system state was. The Sentry Elixir SDK lets you capture this:

Sentry.capture_exception(exception,
  result: :success,
  extra: %{
    user_id: user.id,
    order_total: order.total,
    payment_method: "card"
  },
  tags: %{
    feature: "checkout",
    tier: user.tier
  }
)

For background jobs or asynchronous work, you can also capture breadcrumbs—a timeline of what happened before the error:

Sentry.capture_breadcrumb(%{
  category: "auth",
  message: "User login attempt",
  level: "info",
  data: %{username: email, method: "oauth"}
})

These breadcrumbs appear in the LightTrace issue timeline, making it much easier to understand the sequence of events that led to the crash.

Integrating with Your Release Pipeline

Phoenix's release health monitoring becomes much more useful when error tracking is connected. When you deploy a new release, tag it in LightTrace:

config :sentry,
  release: System.get_env("RELEASE_VERSION")

LightTrace will then show you:

• Which errors are new in the latest release (regressions).
• Which errors have been fixed (no longer appearing in the new release).
• Crash-free sessions for the current release (how many users had error-free sessions).

This turns releases into checkpoints for debugging. If error rate spiked after a deploy, you can immediately see the delta and roll back if needed.

Best Practices for Elixir Error Tracking

Avoid over-reporting. Elixir's crash-and-restart model means transient errors happen. A temporary database connection loss is not an actionable error if the supervisor retries and succeeds. Use before_send callbacks to filter noise:

config :sentry,
  before_send: fn event ->
    if event.exception |> List.first() |> elem(1) == "ECONNREFUSED" do
      nil
    else
      event
    end
  end

Tag by feature and tier. Use tags to segment your errors. Tag by feature flag, user tier, or geographic region so you can ask "are premium users affected?" without digging through individual errors. Distributed tracing becomes easier when you can correlate errors across service boundaries.

Differentiate environments. Staging and production errors should have separate projects (or the same project with clear environment tags). You don't want a flaky integration test bloating your production alert threshold.

Set up alert rules. LightTrace lets you define when to get notified. For example, alert if a new critical issue appears, or if any issue gets 10 errors in 5 minutes. Alerts are delivered by email, so they integrate with your team's existing inbox workflow.

Comparing Approaches

Honeybadger and AppSignal are Elixir-first and deeply integrated with the runtime. If you've standardized on one of them, switching is a big lift. But if you're building a modern stack with multiple languages and frameworks—React on frontend, Node.js services, Python workers, and Elixir backend—LightTrace's unified Sentry protocol gives you one dashboard and one mental model. You configure Sentry SDKs the same way everywhere, and everything reports to the same place.

For smaller teams, cost matters too. LightTrace's pricing (Free for up to 5,000 events/month, then $29/month for 250k events) is built for lean operations. Sentry's pricing is higher, and Honeybadger/AppSignal charge per-application or per-metric. With LightTrace, you pay for throughput, not seat count or feature tier.

Getting Started

Start by testing LightTrace with your staging environment. Deploy the Sentry Elixir SDK, point it at a free LightTrace project, and trigger some test errors. You'll see:

• Grouped issues with automatic fingerprinting.
• Full stack traces with source file links (if you publish source maps).
• Custom tags and context you've attached.
• Release version and environment metadata.

Once you're confident, move to production, set up alert rules, and integrate error tracking into your incident response. You'll catch production issues before users report them, and your team will spend less time SSH'ing into servers to debug silent failures.