Laravel Ohdear Webhooks Laravel Package

Product Decisions This Supports

• Build vs. buy on reliability plumbing. Signature verification done with constant-time hash_equals, a signed route macro, and event-to-job dispatch is roughly a day of engineering. This package makes "buy" a legitimate answer for the plumbing so the team spends its sprint budget on the differentiated part: what happens after a failed check (who gets paged, what the status page says, what the customer sees).
• Incident response feature roadmap. The event vocabulary (uptimeCheckFailed, uptimeCheckRecovered) maps directly to user-facing reliability commitments: "we alert the on-call engineer within 60 seconds," "customers see degraded status automatically," "post-recovery notifications are automatic." Each is a shippable, demoable feature rather than an infrastructure chore.
• Closing the loop between monitoring vendor and product. Once webhooks land in-app, Oh Dear stops being a dashboard nobody checks and becomes an input to your own workflows — support macros, status page states, SLA reporting, account health scoring. That conversion is a product decision, not an infrastructure one.
• Churn and trust instrumentation. Failed-then-recovered checks are a clean signal for account health and proactive outreach ("we caught this before you did"). This requires the events to reach application code, which is exactly the gap this package fills.
• Queue architecture as a deliberate product constraint. The README's insistence on queueable jobs/listeners is a product-facing decision about webhook response latency: fast 200s prevent Oh Dear retries and timeouts. If the team wants per-customer notification SLAs, the async boundary must be settled early.
• Vendor consolidation and lock-in tracking. Adopting this package deepens dependence on Oh Dear. Worth logging explicitly as a decision: what would it cost to move to a different monitor, and does the event abstraction (an array payload plus type()) make that swap tractable?

When to Consider This Package

Adopt when all of the following hold:

• The stack is Laravel (the package tracks Laravel versions actively — L9 through L11, with a 2.0.0 major), and the team is comfortable with service providers, config publishing, and route macros.
• Oh Dear is already, or is about to be, the source of truth for uptime and TLS/certificate monitoring. The package's value is entirely contingent on that subscription.
• Only genuine webhooks should mutate application state — the out-of-the-box signature verification is the main reason to prefer this over a hand-rolled controller. Rolling your own here is where security regressions happen.
• The team wants to own post-webhook behavior (jobs, listeners, notifications, persistence) rather than adopt a bundled workflow engine.

Look elsewhere when:

• You are not on Laravel, or you are on an unusual/older version. The changelog shows release cadence is driven by framework majors, so being ahead of the supported matrix means waiting.
• You need guarantees this package explicitly does not provide. There is no retry policy, no idempotency or deduplication of repeated events, no persistence of webhook history, and no delivery audit trail. If a PM requirement is "we can prove what we were notified about and when," that is application work on top, and should be scoped and estimated as such — not assumed.
• Oh Dear is not your monitor, or you run multiple monitors and want one normalized internal event stream. This is a single-vendor adapter; a unified abstraction would be a build, and this package is at best a reference implementation to imitate.
• You need the webhook receiver decoupled from the app (separate ingress service, multi-tenant fan-out, strict isolation from customer-facing request paths).
• Procurement or support expectations are high. It is a small, low-star, single-maintainer-lineage utility (Oh Dear's own authors, MIT, no listed dependents). Excellent for what it does; not something to bet an SLA narrative on without reading the source — which, usefully, is small enough that a mid-level engineer can review it in an hour.

How to Pitch It (Stakeholders)

To executives: We already pay for uptime monitoring, but the alerts stop at a vendor dashboard. This adds roughly a day of integration work to route those alerts into our own product — so that a failed check pages the right person, updates what customers see, and feeds our account-health and reporting logic. The cost is small and bounded; the return is faster incident response and a reliability story we can put in front of customers instead of a third-party link we don't control. It is a glue layer, not a platform commitment.

To engineering: It is a thin, well-scoped Laravel adapter — signed POST route, constant-time signature check, config-mapped dispatch to your own job or an ohdear-webhooks::<type> event, plus a typed OhDearWebhookCall with payload, type(), monitor(), run(), dateTime(). It deliberately stops at validation and dispatch; everything after is ours. Two consequences to plan for: make handlers queueable so webhook responses stay fast and Oh Dear doesn't retry, and remember there is no deduplication or history — if we need idempotency or an audit trail, we build it, and we should say so up front rather than discover it during an incident. Review the source before merge (it is short), pin the major version, and keep the signing secret in the secrets manager, not .env on a laptop.

What success looks like: median alert-to-acknowledgement time, percentage of incidents opened by our own system rather than by a customer, and zero unverified webhook requests reaching application code.