Site Monitor Laravel Package

Product Decisions This Supports

• Build vs. buy for uptime/health monitoring: replaces a bespoke "is the site up and is anything erroring" cron-and-Slack glue with a maintained Laravel package. The decision this supports is whether uptime/synthetic checks are core product surface (build) or commodity hygiene (buy).
• Roadmap: observability scope. Because this is a first-party Capell-family package, it signals where the CMS ecosystem expects monitoring to live — inside the Laravel app rather than in an external SaaS. That constrains the roadmap: adopting it means your monitoring roadmap is coupled to the Capell/Laravel release cadence, not a vendor's.
• Release-gate criteria for launch. Gives you a concrete, demoable answer to "how do we know the site is healthy after deploy?" — useful for defining go-live checklists and post-deploy verification stories.
• Support and SLA positioning. Monitoring output becomes the evidence trail for incident response; this feeds decisions about support tiers, on-call expectations, and what you promise customers contractually.
• Feature prioritisation of internal tooling. Cheap to trial in one app, so it de-risks the "do we staff an internal observability effort" question with a real cost signal instead of an estimate.

Caveat on this release: v1.1.0 is the first stable cut after a long beta run (through beta.46). Maturity looks good — 46 pre-release iterations implies sustained real-world use — but the release note itself is only a compare link with no enumerated features, breaking changes, or deprecations. Treat the stability signal as inferred, and confirm the diff before committing it to a production monitoring path.

When to Consider This Package

Consider it when:

• You run one or more Laravel applications and want health/uptime signal without adding an external SaaS vendor, its per-seat or per-check pricing, and its data-processing agreement.
• You are already in or evaluating the Capell ecosystem — shared conventions, likely shared release cadence, single upgrade story.
• Your monitoring need is coarse: is the app reachable, are key routes responding, are scheduled jobs and queues alive. That is the category this fits.
• You want monitoring defined in code and versioned alongside the app, rather than configured in someone's dashboard where it drifts from the deployment.
• You need a low-cost proof of concept. One install answers "is this enough for us" faster than a procurement cycle.

Look elsewhere when:

• You need deep APM — distributed tracing, per-query profiling, span-level latency attribution. This is not that, and won't become that.
• You need 24/7 alerting with escalation policies, on-call rotations, and status-page publishing as a product. Buy a dedicated provider.
• Compliance or residency requirements mandate a vendor with a signed DPA and audited SOC 2 posture; self-hosted packages shift that burden onto your team.
• Your stack isn't Laravel/PHP, or you're multi-runtime and need one pane of glass.
• You cannot absorb a package upgrade treadmill. Even at 1.x, a young package's minor releases can require attention; pin versions and budget review time.
• Nobody owns the alerts. Monitoring with no responder is worse than none — it manufactures known-and-ignored failures.

Adoption criteria to confirm before committing: the v1.1.0 diff for breaking changes versus beta.46; documented support window and Laravel version matrix; whether checks are scheduled-task driven (and therefore depend on your scheduler actually running — a real blind spot); where results are stored and how they're retained; and notification channel coverage.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We can add basic site health monitoring to our Laravel applications as an in-house package rather than a subscription. It just reached its first stable release (v1.1.0) after 46 beta iterations, which is a reasonable maturity signal for something this narrow in scope. The cost is low and the trial is reversible, so the decision is not "commit to a monitoring platform" — it is "spend a small amount of engineering time to find out whether we can retire a line item and own this ourselves." Expected benefit: faster detection of outages, and the beginnings of an evidence trail for incident review and support commitments. Expected limit: this covers "is it up and healthy," not deep performance diagnostics — we would still need a separate answer if we ever want that.

For engineering — the practical framing: This is a small, focused addition, not an architecture change. Two things to check before we rely on it: read the beta.46 → 1.1.0 diff for breaking changes and deprecations, since the release note is only a compare link; and confirm the check mechanism doesn't silently depend on the scheduler we already struggle to keep healthy — otherwise the monitor fails in exactly the scenario it exists to catch. Pin the version, define who receives alerts and what they do, and treat the first app as a pilot rather than a standard.

The honest risk statement: a stable 1.1.0 on a young package means the API is settled enough to build on, not that it is battle-tested at scale. Adopt it where the downside of it breaking is a lost afternoon, not a lost incident response.