Parapet + Mailglass

Copy Markdown View Source

Mailglass is an email delivery library. When you attach the Mailglass integration, Parapet translates Mailglass send, reconcile, and webhook events into delivery metrics across three event families you can observe in Prometheus and track via pre-built SLO slices.

Prerequisites

  • mailglass installed in your host app (optional dep — if it is absent, Mailglass never emits the telemetry events the adapter listens for, so the attached handlers stay dormant and harmless; Parapet does not probe for the mailglass library itself)
  • Parapet installed and configured (mix parapet.install)

What it unlocks

Mailglass email events become Parapet delivery metrics across three event families:

  • parapet_delivery_outbound — send-stop events, tagged by outcome, fault_plane
  • parapet_delivery_provider_feedback — reconcile-stop events, tagged by outcome, delay_bucket
  • parapet_delivery_webhook_ingest — webhook exception events, tagged by failure_class, fault_plane

All events carry integration: :mailglass, provider, and channel: :email tags. Optional ref tags included when present: message_id, delivery_id, provider_message_id.

The Parapet.SLO.MailglassDelivery provider uses these metrics for four slices: mailglass_submit_acceptance, mailglass_confirmed_delivery, mailglass_webhook_freshness, and mailglass_suppression_drift. Register it with:

config :parapet, providers: [Parapet.SLO.MailglassDelivery]

Then run mix parapet.gen.prometheus to generate the alerting rules. See Parapet SLO Reference for the full slice catalog.

Activation

Add the adapter when you start your supervision tree, typically in application.ex:

Parapet.attach(adapters: [:mailglass])

This attaches handlers (via :telemetry.attach_many/4) for [:mailglass, :outbound, :send, :stop], [:mailglass, :reconcile, :stop], and [:mailglass, :webhook, :ingest, :exception] (handler id parapet-mailglass-delivery).

Config keys

The Mailglass integration has no Parapet-level config keys. It reads standard Mailglass telemetry events and re-emits them as Parapet delivery events without additional configuration.

Troubleshooting

Metrics are not appearing in Prometheus

Confirm two things: (1) Parapet.attach(adapters: [:mailglass]) was called before the first Mailglass event fired, and (2) your Telemetry.Metrics reporter includes metrics from the relevant Parapet.Metrics.* module. If the reporter is not wired, counters are defined but never scraped.

Telemetry handler raises a conflict error on startup

A second call to Parapet.attach(adapters: [:mailglass]) raises a telemetry conflict because the handler name parapet-mailglass-delivery is already registered. Attach each adapter exactly once at application startup.

The webhook_ingest events include a latency_ms field that is not in other families

Webhook exception events carry a latency_ms field in Mailglass metadata representing the end-to-end delivery latency observed at webhook receipt. Parapet maps this to a delay_bucket tag and also preserves it as a delay_ms measurement key on the emitted event. Use the delay_bucket tag for SLO slices and the delay_ms measurement for histogram-based alerting.