View Source Upgrade to Sentry 14.x

This guide contains information on how to upgrade from Sentry 13.x to Sentry 14.x. If you're on a version lower than 13.x, see the previous upgrade guides to get to 13.x before going through this one.

Replace :enable_logs with :logs

The :enable_logs option was removed.

Setting the :logs option now attaches the Sentry logger handler, and setting :level inside it turns on structured logs. :level now defaults to nil instead of :info.

If you had enable_logs: true, move it into :logs as a :level:

# In config/config.exs

# Replace this:
config :sentry,
  enable_logs: true,
  logs: [metadata: [:request_id]]

# with this:
config :sentry,
  logs: [level: :info, metadata: [:request_id]]

If you only delete enable_logs: true and keep a :logs block without :level, your application still reports crashes but stops sending structured logs.

If you had enable_logs: false, delete it along with any :logs block, since a :logs block now attaches the handler.

If you attach Sentry.LoggerHandler yourself, it sends structured logs when :logs has a :level, or when you pass :logs_level to the handler.

Remove :enable_metrics

The :enable_metrics option was removed and metrics are always on.

If you had enable_metrics: false, delete it. To stop metrics from being sent, drop them in a :before_send_metric callback:

# In config/config.exs
config :sentry,
  before_send_metric: {MyApp.Sentry, :drop_metric}

defmodule MyApp.Sentry do
  def drop_metric(_metric), do: nil
end

Decide Whether to Trace 404 Responses

The new :traces_ignore_http_status_codes option defaults to [404], so incoming requests answered with 404 Not Found are no longer reported as transactions. Outgoing requests aren't affected.

# In config/config.exs

# Trace every response, as before:
config :sentry,
  traces_ignore_http_status_codes: []

# Or ignore more statuses:
config :sentry,
  traces_ignore_http_status_codes: [404, 500..599]

The transaction is dropped only once the response status is known, so the trace has already been propagated as sampled. Services called while handling the request still report their spans, which appear in Sentry without their root transaction.

Check How You Handle Sentry.capture_check_in/1 Results

Check-ins are now handled by the Telemetry Processor by default, and as a result, Sentry.capture_check_in/1 returns {:ok, check_in_id} right away instead of waiting for the HTTP request, and a failure to send the check-in is no longer returned as {:error, reason}. Call Sentry.flush/1 if you need to wait until buffered check-ins are sent.

Check Your Sentry.LoggerHandler Overload Protection

Errors are now handled by the Telemetry Processor by default, so the :sync_threshold and :discard_threshold options of Sentry.LoggerHandler no longer take effect when set above 0. Overload protection comes from the Telemetry Processor instead: it keeps a bounded buffer per category and a bounded transport queue, and drops the oldest items when they are full. You can tune their sizes with :telemetry_buffer_capacities and :transport_capacity.

If you rely on these thresholds, remove :error from :telemetry_processor_categories to keep the previous behavior:

# In config/config.exs
config :sentry,
  telemetry_processor_categories: [:check_in, :transaction]

Review the Default Scrubbed Parameter Keys

Sentry.Scrubber.default_param_keys/0 now returns a longer denylist instead of ["password", "passwd", "secret"], and its terms match as case-insensitive substrings of the key name instead of exact key names. For example, "auth" now scrubs both "Authorization" and "X-Auth-Token".

Parameters that used to reach Sentry may now be scrubbed. See Sentry.Scrubber for the full list. Terms you add with scrubber: [param_keys: ...] extend this list; it can't be shortened.