Usage

Capturing Errors

If you use the LoggerBackend and set up the Plug/Phoenix integrations, all errors will bubble up to Sentry.

Otherwise, we provide a simple way to capture exceptions manually:

try do
  ThisWillError.really()
rescue
  my_exception ->
    Sentry.capture_exception(my_exception, [stacktrace: __STACKTRACE__, extra: %{extra: information}])
end

Optional Attributes

With calls to capture_exception additional data can be supplied as a keyword list:

Sentry.capture_exception(ex, opts)
extra

Additional context for this event. Must be a mapping. Children can be any native JSON type.

extra: %{key: "value"}
level

The level of the event. Defaults to error.

level: "warning"

Sentry is aware of the following levels:

  • debug (the least serious)
  • info
  • warning
  • error
  • fatal (the most serious)
fingerprint

The fingerprint for grouping this event.

tags

Tags to index with this event. Must be a mapping of strings.

tags: %{"key" => "value"}
user

The acting user.

user: %{
    "id" => 42,
    "email" => "email@email.com"
}
event_source

The source of the event. Used by the Sentry.EventFilter behaviour.

Sentry supports capturing breadcrumbs – events that happened prior to an issue. We need to be careful because breadcrumbs are per-process. If a process dies it might lose its context.

Sentry.Context.add_breadcrumb(%{my: "crumb"})