Monitor Laravel Package

Product Decisions This Supports

• Closing an internal-ops “system status” backlog item without buying a platform. If a roadmap line item reads “internal system health page,” orchid/monitor can retire it cheaply — but only as a convenience screen and only if Orchid is already in the stack. Treat it as a checkbox, not a platform bet.
• Deciding whether to standardize on Orchid Platform. This is the decision the package actually forces. orchid/monitor is not an independent observability product; it is a system-information screen bundled inside orchid/platform (the repo is the monorepo theOrchid/Platform). Adopting it without Orchid means adopting Orchid — an admin-surface commitment, not a package install.
• Scoping what we expose to whom. It cleanly separates operator-facing internals (a read-only host readout) from anything customer-visible or SLA-bearing. Use it to draw that line explicitly in access design rather than drifting into it.
• Sizing the “observability” gap honestly. Adopting this does not reduce the work of real observability. It has no history, retention, alerting, error tracking, or uptime. Those remain separate buy decisions — Laravel Pulse/Horizon, Telescope (dev only), Sentry, hosted APM, Prometheus/cAdvisor. Record that explicitly so the roadmap does not double-count this as coverage.
• Cheap adjacent wins, gated on a spike. The underlying Monitor service (cpu(), ram(), disk()) can be embedded into screens operators already use, exposed as a bounded JSON polling endpoint, or used as a post-deploy disk assertion. Each is a small, reversible enhancement with a clean removal path — worth a time-boxed spike, not a quarter of roadmap.
• Decisions it explicitly should not be cited for: alerting design, incident response tooling, capacity planning, container/host observability, multi-tenant status pages, or any customer-facing reliability commitment.

When to Consider This Package

Consider it only when the following are all true:

• Orchid is already our admin panel. The package is effectively a screen for that panel; standalone value is close to nil.
• The need is a lightweight, read-only, point-in-time host readout for trusted internal admins — not real observability. If anyone is asking “was it healthy last Tuesday” or “page someone,” this is the wrong tool.
• We accept the maintenance and adoption risk. Supplied signals are thin: package score 0.3, zero dependents, low opportunity score, no meaningful star traction, and a monorepo layout that makes package-level release cadence and version constraints illegible. We must pin a tested orchid/platform tag, read the changelog on every upgrade, and budget a fork-or-replace exit. One engineer should own it as fallback support.
• The runtime cooperates. Linux in production, and exec/proc_open/shell_exec not disabled — the monitors shell out to top/free/df and produce silently wrong or zeroed values otherwise. No stale NFS mounts, which can hang df with no package-level timeout knob.
• The endpoint can inherit real auth. Monitor routes must carry our actual guards, SSO, and IP allow-lists, not merely panel defaults. This route fingerprints the host; a middleware misconfiguration is an information-disclosure finding.

Look elsewhere when:

• We need real monitoring — metrics over time, retention, dashboards, alerting, error tracking, uptime SLAs. Use Pulse, Horizon, Telescope (dev), Sentry, or a hosted APM.
• We are not on Orchid. Don’t buy an admin panel to get a system-info page; the cost/benefit inverts.
• We need production-grade support, an active maintainer, or a security posture we can point at. The adoption signals here don’t support a critical-path dependency.
• We need customer-visible or multi-tenant status — wrong scope and wrong trust level.
• We need container-native observability. Inside Docker/K8s, /proc and df report the container’s view, not the host’s; the numbers will mislead rather than inform.

Recommended gate: a time-boxed spike with a pre-agreed abandon criterion — confirm Orchid version alignment with our Laravel/PHP baseline, verify shell-function availability and mounts in a production-like environment, and complete a short security review of what system data renders and to whom.

How to Pitch It (Stakeholders)

For executives. This is a small, low-cost convenience screen inside our internal admin panel — it shows operators basic system health (CPU, RAM, disk) at a glance, which can close an existing “internal status page” backlog item. It is not a monitoring or reliability product: no history, no alerting, no retention, no SLA, and it protects no revenue. The material risk is dependency health — the package has essentially no independent adoption and ships inside a monorepo — so we should treat it as “nice to have, easily replaced,” never as infrastructure, and never let its presence be read as “we have monitoring.” Worth adopting only if we have already committed to the Orchid admin panel; it is not a reason to adopt one.

For engineering. orchid/monitor is the system-information screen bundled inside orchid/platform, not a standalone package. With Orchid installed, the monitor screen appears in the admin panel and exposes server metrics (CPU load, memory, disk) plus PHP/Laravel runtime and database connection details. The underlying Monitor service shells out to Linux commands, so confirm exec/proc_open/shell_exec are available in the production runtime, test on Linux rather than macOS, and treat container readings as container-scoped. Cache metric calls, guard the route with real auth and Orchid roles, pin orchid/platform to a tested tag, and read the changelog on every upgrade. Use it as a read-only operator convenience and post-deploy disk check, not as an alerting or historical monitoring system.