Actuator Mailer Bundle Laravel Package

Product Decisions This Supports

• Observability scope for transactional email: decides whether "mail is down" becomes a first-class, machine-readable health signal (e.g., a /health component reporting mailer status) rather than a support ticket triggered by a customer saying "I never got the password reset."
• Platform-version roadmap: v1.1.0 adds Symfony 7.0 compatibility. That converts a previously implicit constraint ("this only works if we're not yet on Symfony 7") into a non-issue, and it means mailer health can be folded into a Symfony 7 upgrade or greenfield build rather than being deferred until after migration.
• Build vs. buy (or rather, build vs. wire up): this is a thin, MIT-licensed health indicator for the Symfony Mailer component inside the ActuatorBundle ecosystem. The decision it informs is "do we spend a sprint writing an in-house health check, or adopt a pre-built one and spend that sprint elsewhere?"
• Roadmap placement of platform hygiene: if your roadmap already includes ActuatorBundle adoption for liveness/readiness endpoints, mailer health is a cheap add-on item — a checkbox on an existing initiative rather than a standalone project.
• Incident response and SLO design: supports decisions about alerting on mail transport failures (bad DSN, revoked API key, blocked SMTP egress) before they cascade into signup, password-reset, or receipt-email failures.
• Use cases it maps to: multi-tenant SaaS with per-tenant mail transports, regulated environments needing demonstrable dependency monitoring, and teams running Kubernetes/ECS probes that want dependency-level granularity.
• Ecosystem fit caveat: despite being catalogued as a "Laravel/PHP package," this is a Symfony bundle tied to symsensor/actuator-mailer-bundle and the ActuatorBundle abstraction. v1.1.0 does nothing to change that — it is a Symfony version-compatibility release. It supports no Laravel product decision. Treat any Laravel-adjacent framing as a catalog error.

When to Consider This Package

Consider it when:

• You are on Symfony and have already committed to (or are actively evaluating) symsensor/actuator-bundle. The value is entirely contingent on that; standalone it is a few hundred lines of glue.
• You are on Symfony 7.0 — as of v1.1.0 this is now a supported target rather than a blocker. If your Symfony 7 upgrade was the reason this sat in the backlog, that reason is gone.
• You want a mailer health indicator without writing one, and the MIT license plus small surface area means you can vendor or fork it without legal or maintenance drag.
• Your mailer configuration is non-trivial — multiple transports, per-tenant DSNs, third-party providers (SES, Postmark, Mailgun) — where a misconfiguration is plausible and silent.
• You are comfortable treating it as low-ceremony, single-maintainer: v1.1.0 is the first movement since v1.0.0 (December 2023) and is a compatibility patch only — no new features, no deprecations, no breaking changes. That is a positive maintenance signal, but one data point is not a release cadence, and there is still no security patch pipeline or community triage to rely on.

Look elsewhere when:

• You are on Laravel — this is categorically the wrong package; use Laravel's built-in health routes, spatie/laravel-health, or an uptime/APM vendor instead. Symfony 7 support does not change this.
• You need vendor-backed SLAs, guaranteed maintenance, or a support contract. A single compatibility release does not constitute a support commitment.
• You need deep mailer verification (send-and-confirm round trips, deliverability/bounce monitoring, reputation tracking). This is a health indicator, not a deliverability platform — pair it with provider webhooks or an ESP's own monitoring.
• Your team has no ActuatorBundle footprint. Adopting a zero-adoption bundle to justify adopting another low-adoption bundle is a compounding bet, not a de-risked one.
• You are still on Symfony 6 and have no near-term Symfony 7 plans — v1.1.0 is not a reason to adopt or upgrade; it simply removes a future friction point. Stay on v1.0.0 if that is what your platform supports.
• You need predictability in the issue tracker or a documented deprecation/support policy.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a small, free, open-source monitoring adapter that lets our infrastructure report "email sending is working" alongside our other health checks. The business case is narrow but real: undetected mail outages show up as failed signups and unsent password resets, which are expensive and embarrassing. The cost is near zero — no license fee, roughly a day of engineering to wire into the ActuatorBundle monitoring layer we would need anyway. The project also just shipped Symfony 7 support, so it is current with the framework version we are moving toward, and it remains MIT-licensed and tiny enough that we can copy it in-house if the original author walks away. Recommendation: not a standalone initiative — bundle it into an existing observability or Symfony 7 upgrade effort, and skip it entirely if we don't already have that foundation.

To engineering — the honest summary: It's a Symfony bundle, not Laravel, and the catalog metadata is still misleading. v1.1.0 is a one-line compatibility release adding Symfony 7.0 support — no features, no breaking changes, no deprecations — so treat the upgrade as low-risk if you're already pinned to v1.0.0. It is also the first tagged release since December 2023, which softens the "possibly abandoned" read but does not establish a cadence; the project still has effectively no community footprint. Keep the operating posture: review the source before adopting (it should be a thin health-indicator implementation against the Mailer transport), pin the version, and vendor or fork it rather than depending on upstream responsiveness. Validate that what it actually checks matches what we need — likely transport/DSN configuration and connectivity, not end-to-end deliverability. If it doesn't fit, the fallback is a short custom health indicator; the effort delta is small enough that this should never block a release.