Ohdear Php Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy on uptime/synthetic monitoring. If Oh Dear is already (or is being considered as) the vendor, this SDK collapses the "build our own monitoring + alerting" option into a two-day integration. The decision becomes a subscription cost line rather than a headcount and infrastructure line.
• Whether to surface site health inside our own product/admin panel. The SDK exposes monitors, checks, check summaries, and certificate health as typed DTOs and enums (CheckResult::isUp() / isDown() / isWarning()), which is exactly the shape needed for a customer-facing "system status" widget or an internal ops dashboard. This is a scope decision: do we show status in-app, or link out to the hosted status page?
• Roadmap for status-page automation. Full CRUD over status pages, updates, and update templates means incident comms can be driven from our own tooling (deploy pipeline, incident bot, admin console) instead of a human logging into the Oh Dear UI. Decide: manual comms, templated semi-automated comms, or fully automated.
• Tying maintenance windows to releases. startMaintenancePeriod / stopMaintenancePeriod / createMaintenancePeriod make it feasible to suppress alert noise automatically around deploys and migrations — a concrete reduction in on-call toil that can be sold internally as an SLO/reliability initiative.
• Agency / multi-tenant onboarding as a product feature. createMonitor plus addStatusPageMonitors supports provisioning a new client site with monitoring and a status page in one workflow — relevant if onboarding speed or "monitoring included" is a packaging differentiator.
• SLA and reporting decisions. Uptime metrics (HTTP timings split by DNS/TCP/SSL/download, ping metrics) and a configurable date range/split mean we can pull real numbers for SLA reporting, quarterly reliability reviews, or customer-facing uptime reports without a data warehouse project.
• Certificate expiry as a risk control. certificateHealth() with getFailedChecks() and getValidUntil() supports a "certificates expiring in 30 days" digest — a cheap way to close a recurring, embarrassing outage class.

When to Consider This Package

Adopt when all of the following hold:

• Oh Dear is already the monitoring vendor, or is the front-runner in an active evaluation — the SDK is a client, not a monitoring system, so it adds no value standalone.
• The stack is PHP, and specifically Laravel or a Saloon-friendly codebase (it is framework-agnostic; it composes cleanly into Laravel but ships no service provider or facade).
• You have a concrete workflow to automate: status-page updates from incidents, maintenance windows around deploys, monitor provisioning at tenant onboarding, or pulling uptime/certificate data into an existing dashboard.
• You can accept a vendor-maintained dependency with low public adoption (roughly 70 GitHub stars, no known dependents) — fine because the vendor is the API owner and the surface is a thin Saloon wrapper over documented endpoints, so the escape hatch is "call the API directly."

Look elsewhere when:

• The team is not on PHP, or you would only ever call Oh Dear from a Node/Python/Go service — use the raw API rather than introducing a PHP service just for this.
• You need observability Oh Dear does not sell (distributed tracing, log aggregation, APM, error tracking). This SDK is uptime/synthetic-checks only; it will not replace Sentry/Datadog-class tooling.
• You need self-hosted or open-source monitoring for data-residency, air-gapped, or cost reasons — Uptime Kuma or a Prometheus/Blackbox stack is the comparison, not this package.
• The requirement is real-time alerting with sub-minute granularity or custom probe locations; validate against the API's check cadence before committing.
• You are buying purely for a public status page and are happy with the hosted one — the UI may be enough, and an integration is over-engineering.
• You need a guaranteed support SLA on the SDK itself; MIT-licensed vendor SDKs come with best-effort maintenance.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed, vendor-official library that lets our own systems talk to our website monitoring service. The strategic value is not the code — it is that it converts a manual, human-in-the-loop process (someone notices a site is down, someone posts a status update, someone remembers to pause alerts during a deploy) into automated workflow. Expected outcomes: fewer alert-fatigue interruptions during planned work, faster and more consistent incident communication, and uptime/certificate data we can put in front of customers without building a reporting pipeline. Cost is engineering days, not licence fees, and there is no lock-in beyond the monitoring subscription we already pay for — the fallback is calling the same API directly.

To engineering: It is a thin, typed SDK over the Oh Dear API built on Saloon v4 — DTOs for monitors, checks, status pages, maintenance periods and uptime metrics, plus enums for check results so we are not string-matching 'failed'/'succeeded' in our own code. Errors are explicit (ValidationException with a parseable errors() array, OhDearException for the rest) and timeouts are configurable, so it behaves predictably in queue jobs. Integration cost is roughly a composer require plus a token in config — there is no service provider, so wiring is trivial but also our responsibility. Honest caveats: low public adoption, so treat upstream changes as "vendor may move without community pressure" — pin the version and keep our usage behind a small internal adapter so the SDK is swappable for raw HTTP calls. Also worth confirming the specific endpoints we need are covered before we build on it; the README is thorough but the API surface is the source of truth.