Laravel Appkeep Laravel Package

Product Decisions This Supports

• Build vs. buy for Laravel observability: AppKeep sits in the same decision space as Laravel Telescope/Horizon, Spatie's Laravel Health, Oh Dear, Sentry, and Datadog — but pitched as a single, lightweight toolkit covering uptime, app health, queues, and scheduled commands. That makes it a candidate for the "do we buy a hosted monitor, assemble open-source pieces, or build our own /health + scheduler heartbeat?" decision.
• A specific wedge worth testing — "no SSH access": The stated differentiator (works without SSH) targets teams on managed hosts (Forge, Vapor, Cloud, Platform.sh, shared hosting) where you cannot tail logs or run artisan on the box. If your customer base includes managed-hosting teams, that is a real segment you may currently under-serve.
• Roadmap sequencing: Last release was 2023-08-18, v0.6.2 is a narrow patch (PHP 7.4 SpecContext memory-parsing fix), the repo has effectively one star, and the product is gated behind a private beta. Treat this as a spike/evaluation dependency, not a standard. Any promotion to a customer-facing dependency should wait for 1.0 and a public, documented support matrix.
• Scope calibration for internal tooling: The shipped surface we can verify is small (spec/environment capture, health checks, keep-alive). If your actual need is "a /health endpoint and a queue/scheduler heartbeat," the build-vs-buy math may favor an internal helper — evaluating this package is a cheap way to price that.
• Support & MTTR workflows: Health and queue/scheduler visibility maps directly to reducing time-to-detect and time-to-recover. Useful to size the value of "catch it before users report it" before committing to a paid APM.

When to Consider This Package

Consider it when:

• You run Laravel and want lightweight, in-process uptime/health/queue/scheduler checks without standing up a full APM stack.
• Your infrastructure blocks SSH (managed hosting, PaaS, restricted prod access) and hosted monitoring feels heavy or expensive.
• You are prototyping internal diagnostics and can tolerate pre-1.0 semver churn plus private-beta access friction — pin the exact version and read every changelog.
• You want a small, inspectable, Apache-2.0 dependency for compliance-sensitive or air-gapped-adjacent contexts, and can wrap it behind your own interface.
• You still have PHP 7.4 nodes in a migration window — the 0.6.2 patch shows the maintainer is tracking that case.

Look elsewhere when:

• You need vendor SLA, LTS guarantees, or a security review with a maintenance commitment. One star, a single org, a stale release cadence, and a private beta are all disqualifying for a production standard.
• You need rich observability — distributed tracing, sampling, alert routing, anomaly detection. Sentry/Datadog or Laravel Telescope + Horizon cover that scope far better.
• You need a stable public API. 0.x permits breaking changes in minors; anything customer-facing should wait for 1.0 or stay behind your abstraction.
• You want the safe default. Spatie Laravel Health, Oh Dear, and Laravel's built-in health route are more mature, documented, and widely adopted.
• Your fleet is PHP 8.2/8.3 only and you need explicit confirmation of modern version coverage — the 7.4 fix is not evidence of that.

Practical evaluation gate before adopting: confirm (a) runtime vs. require-dev, (b) tested Laravel/PHP matrix in CI, (c) whether SpecContext failures are loud or silent, (d) memory_limit = -1 / 0 / suffixed edge cases are regression-tested, (e) whether beta access is actually obtainable. If any of these are unresolved, stop at the spike.

How to Pitch It (Stakeholders)

To executives: This is a small, early-stage Laravel monitoring package that promises uptime, health, queue, and scheduled-command checks without SSH access — a real gap for managed-hosting customers, but delivered by a one-star, single-maintainer project that is still in private beta and has not shipped since mid-2023. It is not a platform bet. Recommend a capped, two-week spike in one internal service, evaluated head-to-head against one mature alternative (Spatie Laravel Health or Oh Dear). Cost of adoption is a few engineer-days; cost of reversal is near zero if it stays behind an internal interface. Do not standardize until 1.0 or a public support matrix exists.

To engineering: Treat as pre-stable and possibly narrow. The only release we can verify (v0.6.2) is a patch fixing SpecContext failing to read memory size on PHP 7.4 — no features, no breaking changes, no deprecations. The marketing says "complete monitoring toolkit"; the artifact trail says "small spec/health utility plus a beta roadmap." Pin 0.6.2 exactly, add it as require-dev first, verify no service-provider side effects (middleware, config, migrations), and put a CI test around spec capture on every PHP version we actually deploy. The decision review trigger is either the package hitting 1.0 with confirmed 8.2/8.3 support, or our PHP 7.4 fleet retiring — whichever comes first. If the spike shows we only need a /health route and a scheduler heartbeat, build the ~100-line internal version instead.