Ohdear Cli Laravel Package

Product Decisions This Supports

• Build vs. buy for external monitoring. The CLI is a nearly free evaluation harness for Oh Dear as a vendor: one install, one API token, and an engineer can validate uptime, certificate, DNS, broken-link, mixed-content and scheduled-task checks against real properties in an afternoon. That produces a concrete "buy" recommendation with a real试用 cost instead of a slide deck.
• Deploy-gating and CI policy. The real product decision is whether a release pipeline should block on external health signals. Because the CLI is non-interactive and scriptable, it makes "fail the deploy if the site is unhealthy" a cheap experiment to run for one sprint before committing to it as policy.
• Ops/DX roadmap: vendor CLI vs. internal dashboard. If the team's monitoring questions are already answered by a terminal command, that is evidence against funding an internal status dashboard. Conversely, repeated "I need this in Slack / in the app" requests are evidence the CLI is the wrong surface and the API or an internal tool is the right investment.
• Incident response and on-call ergonomics. A single command an on-call engineer can run to triage "is it us or is it the certificate/DNS/third party?" shortens MTTR and reduces escalation to senior engineers. Worth codifying in the runbook if adopted.
• Portfolio/multi-site management (agency or multi-brand). Scriptable per-site checks make bulk auditing of dozens of properties a shell loop rather than a dashboard crawl — relevant if you operate many small sites.
• Vendor consolidation. Choosing Oh Dear (and its CLI) as the single external-check vendor is a decision to retire overlapping point tools; this package is the developer-facing surface of that consolidation.

Framing correction worth flagging in the ticket: this is not a Laravel/PHP library. It is a standalone PHP CLI, installed globally or as a PHAR. It adds nothing to the application's composer.json, emits no events, exposes no service provider, and has no in-app API. The 141 stars and 0 dependents in the score are artifacts of it being a CLI, not signals of immaturity — do not let them drive the decision. The lock-in lives in the SaaS subscription, not the code (MIT, thin API client).

When to Consider This Package

Adopt only when all of these hold:

• You are an Oh Dear customer, or are running a timeboxed evaluation of Oh Dear with budget pre-approved. The CLI requires a paid account and API token; it has no standalone functionality.
• Your engineers already work in the terminal and CI, and the desired outcome is "check health from a deploy script / pipeline" rather than "surface monitoring inside the product."
• You want zero footprint in the application dependency graph — global install or PHAR means no version conflicts, no upgrade treadmill, no security-review burden on the app itself.
• You operate multiple properties where scripted, repeatable checks beat clicking through a dashboard.

Look elsewhere when:

• You are not buying Oh Dear. There is no partial-value path here. Use free-tier uptime checks (Pingdom/Better Stack free tiers, GitHub Actions cron + curl) for a spike instead.
• You need checks inside the application — queue health, scheduler heartbeats, disk, DB connectivity from the app's own context: spatie/laravel-health or Laravel Pulse is the in-app answer; this CLI is external-only.
• You need monitoring data as a product input (status page, customer-facing SLA reporting, alerting into your own systems): call the Oh Dear API directly or use an SDK; shelling out to a CLI and parsing output is not an integration strategy.
• Self-hosted, air-gapped, or data-residency constrained — Uptime Kuma, Prometheus/Blackbox, or Grafana synthetic monitoring.
• Full observability scope (traces, error tracking, logs) — Sentry, OpenTelemetry; Oh Dear is deliberately narrow.
• Single low-stakes site — subscription cost likely exceeds value; a free cron check is sufficient.
• Support/SLA requirements — this is a small-team, first-party OSS CLI; there is no commercial support contract for the tool itself.

How to Pitch It (Stakeholders)

To executives (one paragraph): Oh Dear's official CLI lets any engineer verify site health — uptime, TLS certificates, DNS, broken links, scheduled tasks — with a single terminal command, and wire those checks into release pipelines. It is MIT-licensed, installs outside our application, and adds zero code or dependency risk to our products. Its strategic value is that it makes "buy external monitoring instead of building it" a one-day, near-zero-cost evaluation with a clear kill criterion — and if we adopt, it becomes the standard triage step in incident response. The cost is the Oh Dear subscription, not the tool; the tool itself is a thin, replaceable client.

To engineering (the honest version): It is a CLI wrapper over the Oh Dear API, not a package you require. Install globally or as a PHAR, authenticate with a token, script it in CI. Upside: no app coupling, no upgrade path to manage, trivially removable. Downsides: only useful if we're paying for Oh Dear; output is human-oriented, so treat it as an operator tool, not an integration point — if we need the data programmatically, we go to the API. Maintainer surface is small (Oh Dear / Nuno Maduro), but it is first-party and API-bound, so the blast radius of it stalling is limited to "we call the API with curl instead."

Kill criteria to state up front: if the evaluation shows Oh Dear's checks are duplicative of what spatie/laravel-health plus a free uptime monitor already give us, or if no team commits to putting it in a runbook or pipeline, do not adopt — the CLI has no value as a shelf-ware install.