Ping Laravel Package

Product Decisions This Supports

• Build vs. buy for network diagnostics. ICMP reachability + latency reporting is a small but recurring need (status pages, "is the host up?" checks, pre-provisioning validation). This package converts raw ping output into a typed PingResult (packet loss %, packets sent/received, min/max/avg/stddev latency, per-line timings, error enum). That parsing is the tedious, fragile part — buying it as an MIT dependency is cheaper than owning a parser.
• Feature scoping for an observability/status surface. Enables a "Connectivity" or "Network health" panel: ping a set of hosts on a schedule, store $result->toArray() (JSON column or metrics table), render latency and packet-loss trends. The array/serialization + fromArray() round-trip makes persistence and replay straightforward.
• Support and onboarding tooling. "Test my connection" flows (customer onboarding, VPN/tunnel verification, remote-site diagnostics) can run a few pings with configurable count, timeoutInSeconds, intervalInSeconds, packetSizeInBytes, ttl, and ipVersion (IPv4/IPv6/auto), then surface a human-readable diagnosis instead of a support ticket.
• Roadmap triage: what this package does not decide for you. It is a command wrapper, not a monitoring product. Scheduling, retries/backoff, alert thresholds, notification channels, multi-region probing, TCP/HTTP/DNS checks, and retention/analytics remain our work. Treat it as one primitive inside a monitoring feature, never as the feature itself.
• Risk-bounded adoption decision. 94 stars, 0 dependents, niche scope, MIT license, Spatie-maintained with active releases and a changelog. Low blast radius: if it disappears, the replacement cost is a small internal adapter plus a parser. That makes it a safe "buy" for non-critical paths, but a poor candidate for anything on the revenue-critical hot path without a wrapper interface.

When to Consider This Package

Adopt when:

• We're on PHP/Laravel, deploying to Linux (or macOS for local/dev), and the ping binary is present in the runtime image.
• The need is genuinely ICMP reachability and latency statistics — not HTTP status, TLS expiry, or TCP port checks.
• We want structured, enumerable outcomes (PingError enum) rather than scraping stdout in application code.
• Volume is modest: scheduled jobs, admin-triggered checks, per-customer diagnostics — dozens to low thousands of pings per day, not per second.
• We can tolerate a shell-exec dependency and will pin the version and wrap the package behind our own NetworkProbe interface.

Look elsewhere when:

• Cross-platform (Windows) is required — the README and changelog are Linux/macOS-oriented (the -4/-6 flags are skipped on macOS; showLostPackets is Linux-only). Windows ping output differs materially.
• Scale or always-on monitoring is the requirement — Prometheus blackbox_exporter, Uptime Kuma, Zabbix, or a hosted service (Pingdom/Better Stack) will be cheaper to operate than building scheduling, storage, and alerting around this.
• The runtime can't shell out or lacks raw-socket capability (CAP_NET_RAW/setuid or unprivileged ICMP). This is the most common blocker in hardened containers.
• Output stability matters. Parsing depends on iputils output strings; the 1.2.2 changelog ("recognise more iputils ping error strings") shows error coverage is still being expanded. Localized or non-standard ping builds are a real risk.
• We need contractual support/SLA, or the check sits on a critical alerting path where a silently failed parse must never produce a false "down."
• High concurrency/latency-sensitive paths — blocking subprocess calls in a web request will hurt; this belongs in queued jobs.

Adoption checklist: pin the version, add a wrapper interface with a fake implementation for tests (real pings are skipped in CI upstream, so our own contract tests matter), validate/whitelist hostnames before they reach the process invocation, and confirm the container image ships ping with the right permissions.

How to Pitch It (Stakeholders)

To executives: This is a tiny, free (MIT), actively maintained dependency from a well-known PHP vendor that lets us ship network-visibility features — "is this host reachable, how lossy, how fast" — in days rather than weeks. Cost is one Composer package and a small integration; the risk is bounded because it sits behind our own interface and can be replaced with a few hundred lines of code if we ever need to. It is not a monitoring platform and shouldn't be positioned as one — it's a building block for diagnostics and support tooling.

To engineering: It wraps the system ping and returns a typed PingResult: success/error enum, packet counts and loss percentage, min/max/avg/standard-deviation timings, per-line results, raw output, and toArray()/fromArray() for persistence. Fluent configuration for timeout, count, interval, packet size, TTL, lost-packet reporting, and IPv4/IPv6/auto. Spatie-maintained, active releases through 1.2.x, PHP 8.5 and Symfony 8 in CI. Caveats we should design around: it shells out, is Linux/macOS-focused, requires the ping binary and appropriate socket permissions, and its parsing is only as stable as the underlying iputils output — so we pin the version, validate hostnames, run it from queued jobs, and keep a thin adapter so swapping in a custom parser is a one-file change.