The behaviour every toolbar panel implements, the built-ins included (ADR 05).

A plugin collects events from :telemetry inside the host's processes and, in the panel, folds them into summary badges (summary_init/1, summary_add/2, badges/1) and shows them in its own tab (panel/0, see PhoenixDevToolbar.Panel). Register plugins in config/dev.exs:

config :phoenix_dev_toolbar,
  plugins: [:defaults, {MyApp.Toolbar.Jobs, queues: [:default]}]

:defaults expands to the built-ins (Ecto, Request, LiveView, Process, System). Listing a built-in with options overrides it; {:exclude, Module} removes one. An invalid entry is logged and skipped: the host application always boots.

Example

defmodule MyApp.Toolbar.Jobs do
  use PhoenixDevToolbar.Plugin, id: :jobs, name: "Jobs"

  alias PhoenixDevToolbar.{Context, Event}

  @impl PhoenixDevToolbar.Plugin
  def init(opts), do: {:ok, %{queues: Keyword.get(opts, :queues, :all)}}

  @impl PhoenixDevToolbar.Plugin
  def telemetry_events(_config), do: [[:oban, :engine, :insert_job, :stop]]

  @impl PhoenixDevToolbar.Plugin
  def collect(_event, {measurements, metadata}, %Context{}) do
    data = %{worker: metadata.job.worker}
    {:record, Event.new(:jobs, :inserted, data, duration: measurements.duration)}
  end
end

Where the code runs

init/1 runs once, when the toolbar attaches its handlers. collect/3 runs inside the host process that emitted the event (a request, a LiveView, a Repo caller), and only for processes the toolbar tracks. So it must be cheap and pure:

• never call another process synchronously, never do I/O
• bound everything it keeps: inspect/2 limits, never whole structs
• never create atoms from runtime data

A collect/3 that raises, throws or exits is disabled (quarantined) and the error is logged once; the other plugins keep working.

The behaviour is unstable before 1.0 (see the note at the top).