Statamic Oh Dear Laravel Package

Product Decisions This Supports

• Build vs. buy for site health visibility: Rather than building an in-house uptime/SSL/performance monitoring surface into the Statamic control panel, this addon buys that capability by wrapping an existing Oh Dear subscription. The v2.0.0 release reinforces that bet: the maintainer has kept pace with Oh Dear's API 4, signalling the integration is actively maintained rather than a one-off.
• Roadmap: "site health at a glance" for content and account teams. Editors and site owners who live in the CMS can see monitoring status without a second tool or a second login. This is a low-effort, high-perceived-value roadmap item for agency and multi-site clients.
• Upgrade sequencing decision: v2.0.0 is a major version with breaking changes to method return types. Decision needed: pin to 1.11.x for now, or schedule a v2 upgrade. The changelog claims the breakage "should not affect anyone," which is plausible only if you have not overridden or extended the addon's classes.
• Platform dependency review: The addon is only as durable as Oh Dear's API. API 4 alignment is good news, but it also means older 1.x installs are now further from the vendor's supported surface and may face deprecation pressure as Oh Dear retires prior API versions.
• Vendor/lock-in assessment for the monitoring layer: Confirms monitoring is a pluggable, replaceable layer in the stack rather than something baked into the product — useful leverage in renewal and vendor negotiations.

When to Consider This Package

Consider it when:

• The stack is Statamic (this is a Statamic addon, not a general Laravel package — it will not drop into a plain Laravel app).
• The organisation already pays for, or plans to pay for, an Oh Dear subscription; the addon is a presentation layer, not a monitoring service in itself.
• You want editor-facing visibility of uptime, SSL, broken links, or performance inside the control panel, rather than a separate dashboard someone has to remember to check.
• You are an agency or multi-site operator where reducing tool sprawl and logins has real support-ticket value.
• You can absorb a major-version upgrade with a regression pass on any custom templates, view overrides, or extensions.

Look elsewhere when:

• The application is plain Laravel, WordPress, Drupal, or a headless JS front end — this addon does not apply. The equivalent is Oh Dear's own dashboard or a direct API integration.
• You need deep observability — APM, tracing, structured log aggregation, error tracking, on-call alerting. Oh Dear is uptime/synthetic monitoring; pair it with a dedicated observability tool.
• There is no Oh Dear account and no appetite to buy one — the addon alone provides no monitoring.
• You require guaranteed backwards compatibility or an LTS-style support commitment. This is a single-maintainer open-source addon; v2.0.0's "should not affect anyone" framing is a judgement call, not a contract.
• Compliance or procurement rules demand a commercial support agreement with SLAs.

How to Pitch It (Stakeholders)

To executives: This is a small, free add-on that surfaces the site monitoring we already pay Oh Dear for directly inside the CMS, so editors and account managers see outages and expired certificates without a separate tool or login. The v2.0.0 release is housekeeping: it updates the integration to Oh Dear's current API version (4) and tidies the interface. It is a major version bump because internal method return types changed — a technical formality — and the maintainer states it should not affect normal users. The material risk is low, but the release is unglamorous: no new features. The strategic value is that the integration is still actively maintained, which is the thing to verify before we lean on it.

To engineering: v2.0.0 migrates from an earlier Oh Dear API to API 4 and includes styling adjustments. Breaking changes are confined to method return types and any extended/overridden classes. Recommended path: upgrade in a branch, run the smoke tests on the control panel widgets, and grep for any subclasses or view overrides of the addon before merging. If we have no customisations, the upgrade should be a version bump and a visual check. If we do have customisations, budget a short spike. Also worth flagging: staying on 1.11.x leaves us on an older Oh Dear API surface and increases the chance of a forced upgrade later under time pressure.