Laravel Sitesmonkey Laravel Package

Product Decisions This Supports

• Build vs. buy for observability: Lets us adopt an external monitoring vendor (SitesMonkey) instead of building in-house uptime/health-reporting middleware. The package is the integration layer, so the decision reduces to "which monitoring vendor," not "do we staff a monitoring project."
• Roadmap: reliability and incident response. A single dependency can deliver a first-class health signal for our Laravel services — enough to close out a "we have no production monitoring" gap without a dedicated epic.
• Feature scoping: Informs whether health endpoints, exception forwarding, and deployment verification are table-stakes features we ship ourselves or delegate to tooling. If the package covers them, we deprioritize custom work.
• Use cases to validate: uptime/availability checks, error and exception reporting, post-deploy smoke verification, and SLA/SLO reporting for internal or customer-facing commitments.
• Maintenance-cost tradeoff: A vendor-maintained SDK offloads upkeep of bespoke HTTP calls, retries, and payload formats — a recurring hidden cost we should price into any "we'll just write it ourselves" proposal.
• Vendor consolidation: A decision point on whether SitesMonkey becomes our standard monitoring surface for Laravel services or a point solution for one product.

When to Consider This Package

Adopt when:

• The service is a standard Laravel app and the team has already chosen (or is actively trialing) SitesMonkey as the monitoring vendor.
• We want turnkey wiring — config-driven setup via Laravel conventions — rather than hand-rolled reporting code.
• The product is small-to-mid scale, observability budget is limited, and a thin integration beats a platform investment.
• We prefer a vendor-owned SDK so compatibility tracks the vendor's API rather than our glue code.

Look elsewhere when:

• We've standardized on Datadog, New Relic, Sentry, or Grafana — adding a niche vendor creates monitoring sprawl and split dashboards.
• We need real APM: distributed tracing, profiling, query-level insight. This is monitoring integration, not an APM replacement.
• The stack isn't Laravel, or is heavily customized enough that the package's assumptions don't hold.
• Maturity risk is unacceptable: 0 stars, 0 dependents, and a single recent release mean effectively no community validation. Require vendor support commitments, a documented API, and a rollback path before committing.
• Data residency or compliance review flags what telemetry leaves our infrastructure — confirm payload contents and retention with the vendor first.

How to Pitch It (Stakeholders)

To executives: One small MIT-licensed dependency gets production monitoring onto our Laravel services without engineering build cost or a new headcount line. Code-level lock-in is low — the integration is thin and swappable — but the real commitment is the SitesMonkey vendor relationship, so treat it as a vendor decision, not just a library choice.

To engineering: It's a vendor SDK that plugs into Laravel conventions and saves us from writing and maintaining monitoring middleware ourselves. Adopt it config-driven so the vendor is a config value, not a hard dependency scattered through the codebase. Pin the version, prove it in staging against a real SitesMonkey account, and keep a fallback (simple health endpoint + external pinger) documented.

Honest caveat to state up front: This package is early-stage with essentially zero adoption signals. It's a reasonable bet if we're already leaning toward SitesMonkey and we validate before rollout — not a safe default to adopt on faith.