Service Status Inspector Laravel Package

Product Decisions This Supports

• Health-check and status-page features: If the roadmap includes surfacing "is service X up?" in an admin panel, status dashboard, or customer-facing status page, this package provides the inspection primitive rather than you writing bespoke HTTP probing and response-parsing logic.
• Build vs. buy on dependency health tooling: A maintained, narrowly scoped library is cheaper than owning probe logic, retry semantics, and status normalisation in-house — but only if the surrounding Laravel app also standardises on modern PHP.
• Platform baseline decision (the material one in 6.0): Version 6.0 raises the runtime floor to PHP 8.2 (and tests forward against 8.3). This is effectively a decision gate: adopting 6.x means committing the application and CI matrix to PHP 8.2+, or pinning to 5.x and accepting an unmaintained branch. Treat it as a platform-upgrade input, not a package-upgrade chore.
• Roadmap sequencing: Because 6.0 is a compatibility/maintenance release with no new product-facing capability, it does not unlock new features. It should be scheduled alongside a PHP upgrade, not as a standalone initiative competing with feature work.
• Use cases: internal service monitoring, pre-flight checks before batch jobs, multi-tenant "is the upstream vendor healthy?" indicators, and smoke tests in staged deployments.

When to Consider This Package

Consider it when:

• The application is already on PHP 8.2+ and you accept the 6.x support window; adopting 6.0 on an older runtime is not possible without an upgrade.
• You need service status inspection as a discrete concern — a small, testable component rather than probe logic scattered across controllers and jobs.
• You want a Composer-installable dependency with static analysis (PHPStan) and coding-standard enforcement in its pipeline — a reasonable proxy for maintenance hygiene in a low-activity package.
• Your monitoring needs are shallow and HTTP-based: reachability and reported status. This is not a full observability stack.

Look elsewhere when:

• You need metrics, tracing, alerting, dashboards, or incident history — use a purpose-built platform (Prometheus/Grafana, Healthchecks, hosted status pages). This package will not replace them.
• You require a first-party Laravel integration (service provider, config publishing, queue/event hooks). This is a framework-agnostic PHP library; any Laravel wiring is yours to write and own.
• You need guaranteed long-term support or an SLA. The release trail here is small and single-maintainer; version 6.0 contains only tooling and compatibility work, which signals limited active feature investment.
• You are locked to PHP 8.0/8.1 and cannot move — stay on 5.x and flag the accumulating maintenance risk explicitly.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost building block for showing whether external services are healthy. The 6.0 release adds no new features — it is a housekeeping release that moves the minimum PHP version to 8.2 and refreshes its quality tooling. The real decision is not "should we adopt this library" but "are we on PHP 8.2 yet." If we are, adoption is low-risk and near-free. If we are not, this package becomes one more item on an already-necessary platform upgrade, and we should not adopt it ahead of that work.

To engineering: Version 6.0 is a breaking compatibility release: PHP 8.2 minimum, PHPStan ^1.10, PHP-CS-Fixer fixes, and CI coverage extended to PHP 8.3. No API is documented as changed, so behavioural risk is low and the upgrade is gated entirely on runtime version. Before adopting, confirm (a) our PHP version and CI matrix, (b) that we are comfortable owning the Laravel glue ourselves since no service provider ships, and (c) that HTTP status probing is genuinely all we need — anything beyond that belongs in an observability tool, not here. Recommended posture: adopt 6.x only as part of the PHP 8.2 upgrade; otherwise pin 5.x and record the deferred maintenance as tracked debt.