Laravel Pulse Guzzle Recorder Laravel Package

Product Decisions This Supports

• Observability investment sizing. Laravel Pulse is the first-party, low-cost APM surface for Laravel shops. This recorder closes a specific blind spot — outbound HTTP latency — which is usually where the most damaging third-party failures hide (payments, shipping, auth/KYC, LLM providers, email). It turns "the site was slow" into "Stripe took 4.8s at 14:02."
• Build vs. buy for instrumentation. A competent engineer can write a Guzzle middleware + Pulse recorder in 1–3 days. This package is MIT and free, so the build case is weak unless you need custom tagging, payload capture, or span propagation. Decide once: adopt-and-fork, or build in-house. Don't drift.
• Third-party dependency risk on the roadmap. Once you have per-endpoint p99 outbound latency, you can justify roadmap items like circuit breakers, retry/backoff policy, multi-vendor failover, or moving a call from synchronous checkout flow into a queue. Those decisions are guesswork without data like this.
• SLO and on-call design. Supports defining SLOs on outbound dependencies ("99% of PaymentIntent calls < 800ms") and feeds incident triage. Also informs whether Pulse alone is enough or whether you need real distributed tracing.
• Vendor consolidation. A useful data point when evaluating "do we renew Datadog/New Relic for a Laravel app, or is Pulse + a handful of recorders enough?" At 17 stars and 0 dependents, this is a tactical argument, not a strategic one — but it's real money for small teams.
• Use cases where it shines: debugging intermittent timeouts in a queue worker, proving a vendor's SLA breach during a postmortem, catching a slow endpoint introduced by a new integration before customers do, and answering "is our checkout slowness us or them?"

When to Consider This Package

Adopt when most of these are true:

• You already run Laravel Pulse in production (this package is worthless standalone — it's a recorder, not a monitor).
• Your outbound calls go through Guzzle, which in Laravel almost always means Illuminate\Support\Facades\Http (the Laravel HTTP client is a Guzzle wrapper). This is the key point: most Laravel teams get coverage without touching Guzzle directly.
• You need latency signal, not payload visibility. The package records slow requests into Pulse's Slow Outgoing Requests view; it is not a tracer, not a request/response body logger, and not an alerting system.
• You're comfortable with a small, single-maintainer, 17-star, 0-dependent codebase. Treat it as vendored source you may fork, not as infrastructure you rely on being patched.
• Your team is small enough that "one more dashboard tile in the tool we already have" beats standing up OTel/Jaeger.

Look elsewhere when:

• You need distributed tracing, span context propagation, or cross-service waterfalls — that's OpenTelemetry, Sentry, or Datadog, full stop.
• You need alerting/paging on outbound degradation. Pulse is a dashboard; you still need thresholds and notification wiring around it.
• You need sampling control, per-endpoint tagging, or PII-safe payload capture — plan on forking or building in-house.
• You're not on Laravel, or you use a non-Guzzle client (Symfony HttpClient, cURL directly, SDKs with bundled transports), where coverage will be partial or zero.
• You're already paying for an APM with outbound dependency mapping. Adding a second, weaker source of truth creates arguments in incidents rather than resolving them.
• Version risk matters to you. Verify compatibility against your Pulse major version before committing; the release cadence of a project this size is not a guarantee.

How to Pitch It (Stakeholders)

For executives (one paragraph): Outbound API calls — payments, shipping, identity, email — are the part of our stack we can't see and can't control. When one of them degrades, we currently learn about it from support tickets, not from our own systems. This is a free, MIT-licensed extension to Laravel Pulse, the monitoring dashboard we already own, that records slow outbound HTTP calls with their latency. It costs no license fee and adds no infrastructure. It won't prevent an outage, but it cuts the time between "something feels slow" and "it's the payment provider, and here's the timestamp and duration" from hours to minutes — which is the difference between a status page update and a postmortem. The honest caveat: it's a small community project, so we should treat it as code we own and can fork, not as a vendor relationship.

For engineering (the practical case): It's a Guzzle middleware plus a Pulse recorder — install, register the recorder, done. No call-site changes, and because Laravel's Http facade is Guzzle underneath, existing Http::post(...) calls are captured for free. It surfaces into the Slow Outgoing Requests Pulse card alongside your existing slow-query and slow-job data, so incident triage happens in one place. What it is not: a tracer, an alerting layer, or a body logger. If we outgrow it, the migration path is OTel instrumentation — this is a cheap stopgap that buys us real data now and tells us whether the bigger observability spend is justified. Recommend adopting behind a feature flag, pinning the version, and budgeting half a day to read the source before we depend on it.